Conference PaperPDF Available

Securing the Internet of Things with Recursive InterNetwork Architecture (RINA)



Content may be subject to copyright.
Securing the Internet of Things with
Recursive InterNetwork Architecture (RINA)
Toktam Ramezanifarkhani and Peyman Teymoori
Department of Informatics
University of Oslo
Email: {toktamr|peymant}
Abstract—Communication technology improvements have in-
spired the idea of connecting almost every things to the Internet:
from home appliances, medical devices, and cars, to large infras-
tructures. A unified and secure network of these things is almost
a dream because the Internet has not had this goal from the
beginning; protocols have been implemented and then secured,
and then extended to new domains. This has been the cause of
many vulnerabilities so far. In this paper, we take a fundamental
look at the inherited architectural security issues of Internet
of Things (IoT) which have raised serious security concerns
due to its overwhelming number of nodes. Then, we investigate
Recursive InterNetwork Architecture (RINA), a very promising
network architecture, as a design solution; we demonstrate
how RINA can specifically address security challenges of IoT
networks, and how it mitigates their common attacks. Moreover,
we will show how RINA can provide other features which are
now mentioned as the future trend in IoT.
Security is a critical challenge, especially in Internet of
Things (IoT) and more clearly, (from Cisco) Internet of Every
Things (IoE). “Things” including electronic devices, software,
sensors, and actuators are connected and communicate with
each other, enabling them to be deployed in a variety of
environments and domains such as home and buildings, smart
infrastructure, health, and mobility, i.e. in the whole society.
Being highly deployable in one hand, and the lack of security
preservation in devices, with the potential risk of a large
number of unsecured connected devices on the other hand,
cause the concept of IoT. The number of IoT devices is
predicted to reach 41 billion in 2020 with an $8.9 trillion
market [1]. Communication between IoT devices through
the “smart, connected products” needs a strong, secure, and
scalable communication infrastructure.
While current infrastructures have difficulties in diversity of
services and configurations, management of network commu-
nication for smart infrastructure becomes a bigger challenge;
one of the main challenges is that existing networks and sys-
tems are generally not homogeneous and they are hardly able
to communicate with each other. In addition, secured com-
munications between systems is another significant challenge.
What is needed is a well-established secure communication
across different industrial domains to provide domain synergy.
Unification plays a significant role to foster reusability and
interoperability in systems, and it reduces extra costs.
Comprehensive studies such as [2], [3] on IoT security have
confirmed that many vulnerabilities stem from the currently-
employed network stack protocols of IoT devices and their
interoperability issues with the Internet. For example, although
DTLS can provide security at the transport layer, it makes dif-
ficulties in the operation of CoAP proxies; IPSec can be used
at the network layer, but it hides all the transport information
which affects network performance in wireless environments
[4]; and provided (security) functionalities by current protocols
are not sufficient [5]. Although some research work (e.g.
[6], [7]) focused on presenting a secure IoT architecture,
the presented architecture usually operates at higher layers
regardless of what the network stack is. On the contrary, in this
paper, we fundamentally looked at the security issues of lower
layers, and especially the network stack and its protocols.
To address the above issues in IoT networks, in this paper,
we show how Recursive InterNetwork Architecture (RINA)
can be effectively employed as a secured network stack, and
how much its recursive architecture can facilitate domain
synergy through a unified interoperable and programmable
architecture. RINA was first introduced in [8] and then, imple-
mented and evaluated by a number of international projects.
Through a number of research work (e.g. [4], [9], [10], [11],
[12], [13]), it has demonstrated a very promising potential
in improving network performance and security. RINA uses
the idea of recursion; it defines a layer as a foundation with
basic mechanisms to provide Inter Process Communication
(IPC) between two IPC Processes (IPCP). This layer is called
DIF (Distributed IPC Facility) in the RINA vocabulary. The
mechanisms in DIF can be customized through policies. Then,
DIFs can be recursively reused or arranged arbitrarily; they can
be stacked, chained, or put side-by-side [4]. The recursion
reduces the number of required protocols, mechanisms, and
security efforts at different network layers since the same
program is instantiated. Since every DIF (layer) is naturally a
“secured container”, security is a byproduct of RINA [9].
In Section II, we discuss current security challenges of IoT;
we focus on the network protocol stack and evaluate issues of
common protocols employed in each layer, and we illustrate
how the issues are rooted in the architectural design of the
stack. In Section III, we discuss RINA, its security features,
and how it can address IoT security issues through its novel
architecture. In Section IV, to demonstrate effectiveness of
RINA, we adopt common categories of security issues of IoT,
and map RINA security features to the issues and security
challenges. Then, we discuss in details how RINA, as a novel
architecture, can be deployed in IoT networks. In addition,
RINA has been shown effective in addressing future trends in
networks such as mobility in IoT. We also believe that RINA
provides a flexible structure and makes possible to build large
systems from smaller ones in multiple, different domains. As
a result, different security solutions from different contexts
would be easily adjusted and reused in other contexts. This
facilitates composability of systems and systems of systems
originally from heterogeneous environments. Finally, Section
V concludes the paper.
Fig. 1 illustrates a typical network stack of IoT with
common protocols in each layer; up to the MAC layer, IEEE
802.15.4 [14] is usually supported; the 6LoWPAN protocol
[15] enables the transmission of IPv6 over IEEE 802.15.4;
RPL [16] provides routing over 6LoWPAN; TLS [17] and
DTLS [18] represent transport layer security using TCP and
UDP, respectively; and CoAP [19] provides web transfer at
the application layer over UDP (DTLS) with some limited
congestion control features. Since we focus on the network
stack of IoT devices, we do not discuss perception (to perceive
the environment with technologies such as RFIS and GPS)
which is usually categorized as a layer.
Although there has been much research work on securing
IoT, there are still open issues regarding the layers, protocols,
and their vulnerabilities; these issues are thoroughly discussed
by [20], [3]. We argue that IoT security challenges mostly
stem from the architectural design of IoT network stack. The
challenges (named Ci) and their cause are as follow:
C1IoT Network Stack Issues: Despite the lessons learned
from the Internet, the IoT network stack has similar se-
curity issues. Referring to Fig. 1, the 6LoWPAN protocol
does not define any security mechanism, but it makes
the use of IPsec available to provide security between
two communication end points. However, no specific
method has been adopted yet for 6LoWPAN [20]. Since
the 6LoWPAN Border Router typically does not perform
any authentication, IoT networks are still vulnerable [3].
Moreover, encryption at the routing layer hides all the
necessary information of the upper layers; this is one of
the main problems that Performance Enhancing Proxies
(PEPs) [21] are facing in wireless networks because they
cannot break the end-to-end congestion control loop to
start a new one matching the environment properties (e.g.
wired, wireless) [22]. Although there have been proposals
on smart gateways (e.g. [23], [24]) to connect things to
the Internet, the same problem still exists [20].
At the routing layer, RPL [25] is commonly used, which
does not define how to protect RPL communications and
operations from internal attackers, and it also lacks some
key security features [20].
At the transport/application layer, DTLS, as the common
protocol, have been in use to ensure end-to-end security
using CoAP. As its limitations were mentioned by [20],
DTLS does not support multicast communication which
Transport (TLS, DTLS)
Network (IPv6, ROLL RPL)
MAC (IEEE 802.15.4/4e)
PHY (IEEE 802.15.4)
Application (CoAP)
Adaptation (6LoWPAN)
Fig. 1. A typical IoT network stack with common protocols.
is highly required in IoT networks. Due to its end-to-
end security, DTLS also complicates operations of CoAP
proxies in the path. This problem has led to securing
CoAP communications and object security rather than
the transport security provided by DTLS. However, this
approach is not mature yet. Although most of these issues
have been found and tried to be addressed before in the
Internet, however, IoT still faces almost the same issues.
C2Repeated Functionality in Layers/Protocols: As we see,
almost the same (security) functionality needs to be re-
peated/employed/implemented at different layers several
times per protocol while there is “no need to reinvent the
wheel” in several layers. This repetition increases the risk
of making new mistakes/vulnerabilities, and reduces the
reuse degree for future extensions.
C3Global, Public, and Large Address Space: Due to the
overwhelming number of things, IPv6 was employed. It
also comes with its own challenges such as large, public
addresses since each thing should be addressable pub-
licly. Knowing target addresses indeed increases security
challenges in IoT. Since IP addresses are globally public,
adopting them is complicated due to their large size, while
there is no need to expose everything to the widest scope,
i.e. the Internet.
C4Security and Performance Enhancement Conflict: Perfor-
mance enhancement methods such as PEPs and CoAP
gateways are affected inversely by adding security fea-
tures to other layers especially, transport. In other words,
adding (security) functionalities to one layer might inter-
fere proper (and mostly performance) operations at the
other layers [20].
C5Attack Repetition: Current security functionalities of IoT
protocols and their shortages are commonly known, and
they still need extensions [3]. The overwhelming recent
attacks such as DDoS in IoT devices show how historical
attacks are renewed with even more power.
C6Future Extensions: There are also some other issues
regarding the security of, for example, mobile devices
which have not been addressed yet [26]. Even securing a
protocol/layer in IoT does not mean that it is compliant to
other protocols/layers or any future extensions including
mobility, multicast, and QoS [27].
C7Domain Synergy: In cross-domain applications and het-
erogeneous environments, diversity of protocols and poli-
cies and their communication especially from the security
point of view is a new challenge.
A. What is RINA?
RINA [10] is a novel architecture of networking; it follows
a ground-breaking approach to layers in the network protocol
stack that we are already familiar with. RINA was first
introduced by John Day as a pattern in network architecture in
[8]. To have a closer look at what RINA is, first we discuss the
Internet architecture. The global network which is commonly
known as “The Internet” is the network of networks connecting
millions of devices together. Some approaches such as TCP/IP
and the OSI model were presented to layer functionalities
and provide abstractions. However, the models were deviated
during development and improvement, and more importantly,
the Internet was not originally designed securely; TCP/IP
networks had to adopt many other protocols with redundant
functionalities to be able to work. This all has shown to be
complicated to manage or secure [13].
On the contrary, RINA adopts the basic foundation of net-
working: “Networking is Inter-Process Communication (IPC)
and only IPC” [10]. It unifies networking and distributed
computing: the network is a distributed application that pro-
vides IPC. Moreover, it employs a secured layer with basic
IPC mechanisms (i.e. necessary functionalities), and through
a common API, the network administrator is allowed to
arrange/stack these secured layers as needed recursively. Each
layer is called Distributed IPC Facilities (DIF), and is able to
be programmed through policies on-the-fly; policies determine
how mechanisms could operate.
B. RINA Structure and Mechanisms
On the contrary to the other network stacks, RINA recurses
the same layer which is called DIF. The lowest layer, shim
DIF, operates over any lower layer, which could be physical,
or other protocols such as TCP or UDP. DIFs are usually
numbered from 1 (e.g. 1-DIF, 2-DIF) as the lowest, and N-DIF
refers to the current layer one focuses on.
In Fig. 2, a sample arrangement of two layers of DIFs
between two end-nodes and two routers is shown. An IPC
Process (IPCP) is an instance of the same code managing IPC
in each layer at each node. The internal structure of every IPCP
is the same, and it consists of the following mechanisms which
operate at different timescales:
Data Transfer: handles packet transmission including:
Delimiting: a mechanism for encoding Service Data
Units (SDUs) coming from the upper layer/DIF within
Error and Flow-Control Protocol (EFCP): is composed
of two sub-protocols, Data Transfer Protocol (DTP)
and Data Transfer Control Protocol (DTCP), which
handle data transmission.
Relaying and Multiplexing Task (RMT): routes packets
to output ports of the DIF or upwards.
SDU Protection: intended for encryption, compression,
error-code and TTL.
App. App.
Router1 Router2
Fig. 2. A sample RINA topology with two end-nodes and two routers. Every
IPCP has the same internal structure.
Data Transfer Control: handles error, flow, and retrans-
mission control.
Layer Management: includes
Common Distributed Application Protocol (CDAP):
operates on configuration objects, and layer manage-
Resource and flow allocation,
Locating applications,
Security management, access control,
Enrollment, and authentication.
Referring to Fig. 2, the dashed arrows show the path of
data/message exchange between the two applications in nodes
1 and 2. Every IPCP decides how to process a received PDU
from the upper/lower layer; it can pass it to the lower layer,
send it to the other IPCP if the DIF is on the physical medium
(i.e. it is a 1-DIF), routes it to another IPCP in a lower DIF if
it knows where the destination is (e.g. the IPCPs in 2-DIF in
the routers), or pass it upwards to the destination application
(at node 2). Therefore, there is a single type of layer with
programmable functions, that repeats as many times as needed
by network designers. It means that all layers provide the same
mechanisms: instances or communication (flows) between two
or more application instances, with certain characteristics
(delay, loss, in-order-delivery, etc). However, the mechanisms
are programmable/customizable through policies. In general,
there are only 3 types of nodes in RINA: hosts, interior1and
border routers, and there is no need for middleboxes such
as firewalls, NATs, etc. because policies can customize the
internal behavior of each IPCP (or DIF), which consequently
empowers nodes with any required functionality.
C. RINA Security Features
In addition to the above, RINA improves security as the
byproduct of its design. As mentioned by [10], [11], [9] in
detail, these features are summarized as follows:
F1Secure DIFs: “DIF is a secure container” [9]. RINA
secures layers instead of protocols. Every PDU leaving
N-DIF towards an (N-1)-DIF can be protected by the
SDU protection module meaning that RINA protects N-
DIF PDUs in their entirety as they cross the N-1 DIF
boundary. Even control information (addresses, flow-ids,
etc.) can be protected from the layer below. This solves
1Interior routers are not shown in the figure. See [11] for a complete
the PEP problems with breaking secure connections by
intermediate nodes [4].
F2Divide and Conquer: Through DIFs and recursion, the
problem of securing a wide scope (e.g. as wide as the
Internet scale) will be divided to the problem of securing
smaller scopes. Compromising the protection of some
DIFs does not compromise the whole network [10].
F3Hidden Addresses: In RINA, applications cannot observe
addresses; each DIF has its own addressing which is
hidden from other underlying DIFs. On the other hand, IP
addresses are public in the Internet with no authentication.
F4Communication via a Common DIF: On the contrary to
the Internet, two applications are only able to commu-
nicate if they have a DIF in common. Otherwise, they
should join or create a common DIF.
F5Authentication: Every IPCP should be authenticated first
before joining a DIF. This is performed before connec-
tion management through the enrollment process, and
enrollment does include access control. This means that
attackers have to join a DIF to be able to address IPCPs
in that DIF which requires authentication first.
F6Firewall: Every router will naturally play as a firewall in
RINA. Security modules in IPCPs can provide firewall
F7Programmable DIFs: Any new functionality, which might
address some security, privacy, or performance issue, can
be simply developed as a policy and plugged into existing
mechanisms. This reduces functional redundancies in
protocols and the risk of causing new vulnerabilities by
reducing required efforts.
F8Access Control: Authorization in RINA is performed by
the Access Control module in IPCP, and uses CDAP as
the signaling protocol. This mechanism determines if a
requesting entity is allowed to access a given resource.
F9Synchronization-Independent Port Allocation: RINA de-
couples port allocation from the synchronization process
happening in protocols such as TCP, which reduces the
chance of intercepting a connection and makes attacks
harder to mount.
F10 Port-Independent Communication: In RINA, there is no
well-known ports to listen to; applications are requested
for service through their application name.
F11 Soft-State Connection Management: In RINA, there is
no explicit control messages for connection establish-
ment/close. The state is deleted at the receiver after
2MPL (Maximum Packet Lifetime) which reduces con-
nection management misuse [9].
F12 Connection Management Independent Authentication:
Authentication is decoupled from and performed before
connection management in RINA. This means that just
insiders (authenticated IPCPs in a DIF) can attack.
F13 Insiders Resistance: RINA uses a wider range of con-
trol field values (e.g. connection/QoS id). Given that
an attacker can somehow compromise authentication or
without the support of cryptography, RINA’s typical
field lengths in packets are still long enough to make
attacks harder to succeed, e.g. 248 possibilities to guess
the connection information in RINA compared with 229
possibilities in TCP during data transfer [9].
F14 QoS: Every connection in RINA is established after the
source represents its QoS requirements which include
maximum requested bandwidth [28]. Deviating from
those, e.g. in DoS attacks by congesting the network, can
result in dropping its packets at the first routing node,
which is some form of DoS prevention.
F15 Variable Address Space: Every DIF has its own address
space, which could be smaller or larger, depending on
the number of nodes in that DIF. This saves more space
in the packet header. Hence, not only the addresses are
not clear for attackers, but also the address length is not
known which results in another obstacle in length attacks.
F16 Mobility: Mobility management in RINA is smoothly
performed since every IPCP at every DIF can seamlessly
join/leave DIFs without losing its name in its own DIF.
It just needs some local routing updates at lower DIFs,
without any side-effects on security [10]. In addition to
mobility, RINA can also improve multi-homing [29].
F17 Resiliency: In each DIF, (multi-path) routing is performed
independently and transparently to the other DIFs. This
means that each DIF can provide resiliency services as
well to the upper DIFs. In addition, this property provides
“transport over heterogeneous networks” [30].
F18 Performance Improvements: In addition to the above
security features, RINA has some other important features
which are all very appealing for IoT networks [31]. For
example, through some research work2and international
projects3, it has been shown that RINA can effectively
improve the network performance in terms of throughput
and delay without compromising security [4].
F19 Complexity Reduction: Considering the number of pro-
tocols, required flows, and especially required distinct
mechanisms, RINA networks can satisfy security require-
ments with less complexity than in the current Internet.
Moreover, the number of active instances of networking
mechanisms is reasonably less complex in RINA with
a secured link layer [13]. Rina also reduces the size of
routing tables [12], [32], [33].
F20 Arbitrary Arrangement: DIFs can be arranged/stacked
arbitrarily to provide different operations such as PEPs,
multipath routing, and in-network resource sharing with-
out compromising security [4].
A. How RINA Addresses Security Challenges
RINA approaches problems in a divide-and-conquer man-
ner; it defines different scopes (DIFs) with their own security.
Every N-DIF (including its IPCPs) is responsible for its
security; insider IPCPs are all trusted/pre-authenticated. DIFs
2A complete list of publications on RINA can be found in
can be stacked arbitrarily without the need for developing any
new layer/protocol. When a DIF is secured, the same code is
reused for upper layers. This mimics tunneling in the Internet.
A classification of IoT device attacks includes physical,
network, software, and encryption attacks [2]. Physical attacks
can be performed by short-distance attackers and a part of
the countermeasure is to verify the device authentication
[2]. Although RINA is vulnerable to insider attacks, each
device in the environment has to authenticate itself before
communication which can prevent this kind of attacks. In
addition, devices should employ an error detection system, and
all of their information has to be encrypted to maintain data
integrity and confidentiality, which is possible through DIF
programmability. For network attacks, authentication mecha-
nisms and point-to-point encryption are proposed to ensure
privacy of data and rooting security. Again, RINA authentica-
tion mechanisms in addition to the possibility of utilizing other
security mechanisms such as encryption via SDU protection
is suitable to defend against these attacks. Since RINA nodes
(IPCPs) also play the role of firewall, they can prevent illegal
data access or harming the system against application and
software-based attacks despite their vulnerabilities; this could
be thought as a complementary defense in the presence of
other tools such as anti-viruses. However, the last category
which is called encryption attacks can be prevented as before
by using other existing mechanisms in RINA.
In Table I, we summarize the most security challenges of
IoT networks, and how RINA can address those using its
features. We focused on a number of common network and
application attacks, security properties, and the IoT architec-
tural challenges discussed in Section II. The attacks category
is taken from [5] which discusses in detail how they affect
IoT networks.
Denial of Service (DoS) and Distributed DoS attacks are
historically considered as one of the major security threats and
among the hardest security challenges. Although there are lots
of proposed defense mechanisms against them such as packet
filtering or intrusion detection systems, they are making the
headlines frequently and have become the hugest cyberattacks.
In addition, they are improved and extended several times in
different platforms, e.g. in case of Mirai attack [34].
Referring to the table, DoS attacks can be pre-
vented/mitigated by F5,F10,F11 , and F14. This means that
the attacker cannot be an outsider (F5); he/she should join
the DIF first or create a new one. Moreover, the preceding
step in these attacks is flooding, but there is no listening
port to be the target of such attacks (F10). In addition,
since connections in RINA do not need to wait for explicit
control messages to terminate (F11), flooding attacks and their
impacts are significantly mitigated. Even for an insider, there
are mandatory QoS requirements that the flow should obey
(F14), and any deviation from that by the sender can result in
dropping packets at routers.
To defend against spoofing attacks such as IP (address)
spoofing that exploits valid and authorized IP addresses, RINA
hides internal DIF addresses (by F3) and decouples port
Challenges RINA Features
Denial-of-Service F5,F10,F11 ,F14
Spoofing F3,F5
Sinkhole F1,F2,F6
Wormhole F1,F2,F6
Man in the Middle F1,F5,F9,F13
Routing Information F1,F3,F5,F6
Sybil F1,F5
Unauthorized Access F5,F8,F12
Phishing F1,F5,F8
Malicious Virus/Worm F5,F6
Malicious Scripts F7
Privacy F1,F4,F7
Authentication and Nonrepudiation F5
Access Control F8
Integrity and Confidentiality F1
C1: Network Stack F1,F2,F17,F19
C2: Rep. Functionality F1,F7,F20
C3: Address Space F2,F3,F15
C4: Sec.&Perf. Conflict F1,F2,F20
C5: Repeating Attacks F1,F5,F13
C6: Future Trend F7,F14,F16 ,F17,F18
C7: Domain Synergy F1,F2,F4,F17,F20
allocation from the synchronization (by F9), and also F5
makes sure that no DIF outsider can attack.
In sinkhole attacks, a compromised device tempts the others
to use that them in a data routing process. In addition to
secure routing protocols (provided by F1,F2) useful to prevent
these attacks, the capability of having firewall functionality in
routers, i.e. F6is helpful. This feature (F6) can similarly pre-
vent wormhole attacks as well. In addition, since performing
some attacks such as DoS is the prerequisite of the others to
compromise a device, prevention of DoS attacks can be used
to prevent sinkhole attacks. However, to keep the table simple,
we have mentioned the least features that can directly satisfy
a security requirement, solve a challenge, or prevent an attack.
For the rest of the network attacks in Table I, it is shown how
security features of RINA can prevent/mitigate the attacks,
which is straightforward, and hence, we skip discussing them.
For the application attacks such as phishing, authentication
(F5) and authorization (F8) can be used for mitigation. The
prevention of the other application attacks are also shown in
the table. Preserving the security requirements shown in the
table will prevent some attacks. For example, confidentiality
preservation can mitigate the impact of malicious scripts.
As discussed by a lot of work such as [5], [26], preserving
privacy is another important issue in IoT. We see that RINA
provides a simple way of addressing privacy; for example,
RINA can use a wider range of control field values for privacy
tags. Moreover, due to the ability of policy enforcement
in RINA, i.e. F7, privacy-preserving access control can be
applied. In addition, a common DIF with its invisible addresses
(F4) can be used to preserve anonymity and privacy policies.
As we also see in the table, RINA can address confidentiality
and integrity through RINA SDU Protection module [13]
(feature F1) as well as other security challenges in IoT
networks through a unified, recursive architecture. Authentica-
tion, access control, and integrity and confidentiality are also
addressed by F5,F8, and F1, respectively. Moreover, for these
requirements, RINA has specific security modules [13].
The table also discusses how RINA can address the archi-
tectural security challenges of IoT we introduced in Section II.
For example, the secure DIFs (F1) and divide and conquer (F2)
features in RINA can solve the problem of non-considered
security in stack layers. For instance, non-supporting authen-
tication in 6LoWPAN is solved by the authentication support
in RINA security modules; the transport multicast support and
proxy compatibility are simply addressed by the F17 and F1,
respectively because each DIF has its own security/routing,
and different arrangements of DIFs, as shown in [4], and
their reduced complexity (F19) can simply provide the above
C2is naturally solved by RINA with DIF recursiveness (we
can arbitrarily arrange/stack secure DIFs) and programmability
(DIFs can be customized via policies), and there is no need to
develop new protocols as the same code (IPCP) is instantiated
recursively4.C3is handled by creating DIFs to divide the
widest scope into smaller, simpler scopes (DIFs) by F2with
their own hidden and variable-length address space (F3,F15).
C4is simply solved by the property that in RINA, each
DIF is inherently a “secured container” (F1), and DIFs can
be arranged/stacked without compromising the security of
each other (F2,F20). Therefore, proxy operations do not
interfere the security of other layers. C5is usually prevented
by forcing users/IPCPs to enroll themselves first in secure
DIFs (F1,F5), and it is also more difficult for DIF insiders to
perform attacks (F13). Any future need, C6, can be addressed
through RINA’s programmability (F7) which is inherent in
the current RINA architecture, and the other features such
as QoS (F14), mobility (F16 ), and resiliency (F17) without
compromising security. Finally, domain synergy (C7) can be
simply handled by the recursion property of RINA (F2,F20)
and secure, common DIFs (F1,F4) without any side effects on
the underlying security/performance, regardless of the beneath
network environment (F17).
Domain synergy and how to have a reference architecture is
an important challenge in IoT. For example, we are working
on such a reference architecture in the SCOTT project5to
foster security, reusability, scalability, and interoperability. The
objectives are to leverage the future IoT design middleware
mechanisms and the supporting tools needed between different
industrial domains with different requirements. Based on the
unification provided by RINA, a reference architecture can be
conducted similarly with higher reusability and manageable
policies across different domains. In addition, in the huge and
cumbersome synergies between domains with different refer-
ence architectures, based on some work such as [13], RINA
DIFs promote reducing the scope of networks significantly.
However, there are still some challenges such as traditional
authentication and authorization methods that may not be
4All IPCPs in Fig. 2 are instantiated from the same code.
applicable to the IoT because of heterogeneity and complexity
of objects. Moreover, due to hidden addresses for applications
in RINA, end-to-end authentication and authorization may
encounter new issues. We aim to develop a lightweight and
compatible structure of attribute-based access control policies
[35] for DIFs to overcome these issues. To practically analyze
how RINA is effective to prevent some existing security
challenges, we are focusing on some attractive IoT devices by
attackers such as CCTV cameras that are widely vulnerable to
simple hacks, and we are developing an approach utilizing pro-
grammable DIFs to defeat applicable attacks to these devices.
We are also developing metrics for measuring the security
level of communication to evaluate the RINA architecture in
preventing attacks.
B. RINA Deployment Considerations
One of the main issues in the design of the IoT network
stack is interoperability, i.e. how to guarantee that IoT devices
can communicate with existing Internet applications and fol-
low Internet standards [20]. This has made them adopt many
existing protocols and apparently, inherit their vulnerabilities
and design issues.
Adopting RINA, as a new protocol stack, does imply inter-
operability considerations which are now under investigation
and implementation by some projects such as OCARINA6
that we are working on. As proposed by OCARINA and also
[36], RINA can be deployed as an overlay/underlay/alongside
other networks including the Internet; as an overlay, RINA can
operate on all PHY, Link, IP, and TCP/UDP layers through
its shim DIFs; as an underlay, it can seamlessly transmit,
for example, TCP/IP traffic; and alongside other networks,
through simple proxy IPCPs, it has been shown how RINA
inter-operates with other network stacks. It has also been
investigated how RINA can operate on tiny, limited devices
such as wireless sensors in the RINAiSense project7.
The trend towards connecting everything to each other and
to the Internet has raised serious security concerns. In this
paper, we discussed some main architectural security issues of
IoT networks: security and privacy issues, security limitations
of the current network stack and its employed protocols,
domain synergy, future directions, and expectations from IoT
RINA shows to be a promising network architecture that
has shown significant improvements in many security and
performance aspects. We briefly discussed RINA modules
and security features. By investigating RINA for current IoT
attacks, security requirements and challenges in IoT networks,
we showed that RINA has architectural solutions for each
problem. In addition, it is programmable through policies
which help extend its mechanisms. We believe that the recur-
siveness of RINA and the natural security of each recursion
enables us to build arbitrarily-large secure IoT.
Despite its maturity level, the development of security
protocols for the Internet is still in progress. Likewise, in RINA
some aspects such as key exchange/management have been
recently implemented, and the level of trust in management
data, and integrity-protecting routing are also under active
development. We consider further evaluation of these features
as our future work.
The research leading to these results has received fund-
ing from the SCOTT - Secure Connected Trustable Things.
SCOTT ( has received funding from the
Electronic Component Systems for European Leadership Joint
Undertaking under grant agreement No 737422. This Joint
Undertaking receives support from the European Unions Hori-
zon 2020 research and innovation programme and Austria,
Spain, Finland, Ireland, Sweden, Germany, Poland, Portugal,
Netherlands, Belgium, Norway. Peyman Teymoori was funded
by the Research Council of Norway under its “Toppforsk”
programme through the “OCARINA” project. The views ex-
pressed are solely those of the authors.
[1] “Why the internet of things is called internet of things: Definition, his-
tory, disambiguation,” 2014, of-things-
definition/ .
[2] I. Andrea, C. Chrysostomou, and G. Hadjichristofi, “Internet of things:
Security vulnerabilities and challenges,” in Computers and Communica-
tion (ISCC), 2015 IEEE Symposium on. IEEE, 2015, pp. 180–187.
[3] Y. Yang, L. Wu, and et al., “A survey on security and privacy issues in
internet-of-things,” IEEE Internet of Things Journal, 2017.
[4] P. Teymoori, M. Welzl, G. Stein, E. Grasa, R. Riggio, K. Rausch, and
D. Siracuss, “Congestion control in the Recursive Internetwork Archi-
tecture (RINA),” in IEEE International Conference on Communications
(ICC), Next Generation Networking and Internet Symposium, May 2016.
[5] J. Lin, W. Yu, and et al., “A survey on internet of things: Architecture,
enabling technologies, security and privacy, and applications,” IEEE
Internet of Things Journal, 2017, doi:10.1109/JIOT.2017.2683200.
[6] J. Suarez, J. Quevedo, I. Vidal, D. Corujo, J. Garcia-Reinoso, and
R. L. Aguiar, “A secure iot management architecture based on
information-centric networking,” Journal of Network and Computer
Applications, vol. 63, pp. 190 – 204, 2016. [Online]. Available:
[7] I. D. Addo, S. I. Ahamed, S. S. Yau, and A. Buduru, “A reference
architecture for improving security and privacy in internet of things ap-
plications,” in 2014 IEEE International Conference on Mobile Services,
June 2014, pp. 108–115.
[8] J. Day, Patterns in Network Architecture: A Return to Fundamentals.
Prentice Hall, 2007.
[9] G. Boddapati, J. Day, I. Matta, and L. Chitkushev, “Assessing the
security of a clean-slate internet architecture,” in 20th IEEE International
Conference on Network Protocols (ICNP). IEEE, 2012.
[10] J. Day, I. Matta, and K. Mattar, “Networking is IPC: a guiding principle
to a better internet,” in Proc. ACM CoNEXT, 2008, p. 67.
[11] E. Grasa, O. Rysavy, O. Lichtner, H. Asgari, J. Day, and L. Chitkushev,
“From protecting protocols to layers: Designing, implementing and
experimenting with security policies in rina,” in 2016 IEEE International
Conference on Communications (ICC), May 2016, pp. 1–7.
[12] S. Leon, J. Perello, and et al., “Benefits of programmable topological
routing policies in rina-enabled large-scale datacenters,” in Global
Communications Conference. IEEE, 2016.
[13] J. Small, “Patterns in network security: An analysis of architectural
complexity in securing recursive inter-network architecture networks,”
Master’s thesis, Boston University Metropolitan College, 2012.
[14] “Ieee standard for local and metropolitan area networks–part 15.4: Low-
rate wireless personal area networks (lr-wpans),IEEE Std 802.15.4-
2011 (Revision of IEEE Std 802.15.4-2006), pp. 1–314, Sept 2011.
[15] G. Montenegro, C. Schumacher, and N. Kushalnagar, “IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs): Overview,
Assumptions, Problem Statement, and Goals,” RFC 4919, Aug 2007.
[Online]. Available:
[16] P. Thubert and J. Hui, “Compression Format for IPv6 Datagrams
over IEEE 802.15.4-Based Networks,” RFC 6282, Sep 2011. [Online].
[17] E. Rescorla and T. Dierks, “The Transport Layer Security (TLS)
Protocol Version 1.2,” RFC 5246, Aug 2008. [Online]. Available:
[18] E. Rescorla and N. Modadugu, “Datagram Transport Layer Security
Version 1.2,” RFC 6347, Jan 2012. [Online]. Available: https://rfc-
[19] Z. Shelby, K. Hartke, and C. Bormann, “The Constrained Application
Protocol (CoAP),” RFC 7252, Jun 2014. [Online]. Available: https://rfc-
[20] J. Granjal, E. Monteiro, and J. S. Silva, “Security for the internet of
things: A survey of existing protocols and open research issues,IEEE
Communications Surveys Tutorials, vol. 17, no. 3, 2015.
[21] C. Caini, R. Firrincieli, and D. Lacamera, “PEPsal: a Performance
Enhancing Proxy for TCP satellite connections,” IEEE Aerospace and
Electronic Systems Magazine, vol. 22, no. 8, pp. 7–16, 2007.
[22] T. T. Thai, D. M. L. Pacheco, E. Lochin, and F. Arnal, “SatERN: a PEP-
less solution for satellite communications,” in Proc. IEEE ICC, 2011.
[23] D. Bimschas, H. Hellbr¨
uck, and et al., “Middleware for smart gateways
connecting sensornets to the internet,” in Proceedings of the 5th Interna-
tional Workshop on Middleware Tools, Services and Run-Time Support
for Sensor Networks. ACM, 2010, pp. 8–14.
[24] B. Kang, D. Kim, and H. Choo, “Internet of everything: A large-scale
autonomic iot gateway,” IEEE Transactions on Multi-Scale Computing
Systems, vol. PP, no. 99, pp. 1–1, 2017.
[25] R. Alexander, A. Brandt, J. Vasseur, J. Hui, K. Pister, P. Thubert,
P. Levis, R. Struik, R. Kelsey, and T. Winter, “RPL: IPv6 Routing
Protocol for Low-Power and Lossy Networks,” RFC 6550, Mar 2012.
[Online]. Available:
[26] S. Sicari, A. Rizzardi, L. A. Grieco, and A. Coen-Porisini, “Security,
privacy and trust in internet of things: The road ahead,Computer
Networks, vol. 76, pp. 146–164, 2015.
[27] F. A. Alaba, M. Othman, I. A. T. Hashem, and F. Alotaibi, “Internet
of things security: A survey,Journal of Network and Computer
Applications, vol. 88, pp. 10 – 28, 2017. [Online]. Available:
[28] S. L. Gaixas, J. Perell´
o, and et al., “Assuring qos guarantees for
heterogeneous services in rina networks with δq,” in Cloud Computing
Technology and Science , 2016 IEEE International Conference on.
IEEE, 2016.
[29] V. Ishakian, J. Akinwumi, F. Esposito, and I. Matta, “On supporting
mobility and multihoming in recursive internet architectures,Computer
Communications, vol. 35, no. 13, pp. 1561–1573, 2012.
[30] E. Trouva, E. Grasa, and et al., “Transport over heterogeneous networks
using the rina architecture,” in Proceedings of the 9th IFIP TC 6
International Conference on Wired/Wireless Internet Communications,
[31] E. Trouva, E. Grasa, J. Day, I. Matta, L. T. Chitkushev, P. Phelan, M. P.
De Leon, and S. Bunch, “Is the internet an unfinished demo? meet rina!”
in TERENA Networking Conference, 2010, pp. 1–12.
[32] F. Hrizi and A. Laouiti, “Hierarchical small world overlay for efficient
forwarding in volunteer clouds,” in IEEE 31st International Conference
on Advanced Information Networking and Applications. IEEE, 2017.
[33] F. Hrizi, A. Laouiti, and H. Chaouchi, “Sfr: Scalable forwarding with
rina for distributed clouds,” in Network of the Future (NOF), 2015 6th
International Conference on the. IEEE, 2015, pp. 1–6.
[34] “New Mirai variant hits target with 54-hour DDoS,” 2016,
[35] V. C. Hu, D. Ferraiolo, R. Kuhn, A. R. Friedman, A. J. Lang, M. M.
Cogdell, A. Schnitzer, K. Sandlin, R. Miller, K. Scarfone et al., “Guide
to attribute based access control (abac) definition and considerations
(draft),” NIST special publication, vol. 800, no. 162, 2013.
[36] E. Grasa, E. Trouva, S. Bunch, P. DeWolf, and J. Day, “Developing
a rina prototype over udp/ip using tinos,” in Proceedings of the 7th
International Conference on Future Internet Technologies, 2012.
... In [16], it has shown that IoT security challenges of IP-based IoT frameworks mostly stem from the architectural design of the IoT network stack. In addition, comprehensive studies such as [17] on IoT security have confirmed that many issues stem from the currently-employed network stack protocols of IoT devices and their interoperability issues with the Internet. ...
... How RINA connects IPCPs and how their EFCP is connected to each other in different DIFs can provide other benefits than just performance. A complete evaluation is found in [16,38]. Here, we summarize the security features related to EFCP: ...
... These challenge topics were originally published in[16] in a much shorter form. ...
Full-text available
The Internet of Things (IoT) has revolutionized our lives by connecting devices to the internet, enabling automation and simplifying daily routines. However, as IoT is built upon the foundation of older network architectures and protocols, such as the Internet, its integration has brought forth significant challenges, particularly in achieving both transport layer efficiency and security at the same time. This paper presents a comprehensive overview of the current network stacks used in IoT and highlights the issues they face in this regard. We propose a novel architectural approach leveraging the Recursive InterNetwork Architecture (RINA) to address these challenges. We thoroughly evaluate how RINA's unique combination of recursion and networking can effectively reconcile the efficiency-security trade-off inherent in IoT networks; this has the potential to overcome the limitations of existing architectures and resolving the long-standing issue with Performance Enhancing Proxies (PEPs) that cannot operate on encrypted connections. We demonstrate the practical application of RINA through two use cases: a smart home environment, where RINA provides a unified networking framework, reducing the complexities of integrating diverse systems, and a healthcare patient monitoring scenario, where RINA ensures seamless integration of legacy devices while maintaining the advantages of the RINA architecture, including security and efficient data transmission. The paper concludes with a comprehensive discussion on potential future research topics, paving the way for an efficient and secure IoT ecosystem.
... Variable thus eliminating length attacks [10] Fixed and susceptible to cyber attacks Modern networking demands Architectural design of recursion and programmability of DIF accommodate dynamic networking and multi-homing on mobility [11] Add-on protocols ...
... Table III compares some of the key characteristics of TCP/IP and RINA. This article extracts the advantage of Internal addresses and Private ports [8], [10], [22] Hybrid state data transfer Soft-state data transfer [6], [8], [19] Add-on security Inbuilt and integrated security [9], [10] End-to-end congestion control Congestion control at the source level [23] Interface naming Node naming [11] soft-state data transfer in terms of network performance and verifies its handshaking procedures. The application is run for certain time in each network and the network performance is observed for control and data sensing operations. ...
... Table III compares some of the key characteristics of TCP/IP and RINA. This article extracts the advantage of Internal addresses and Private ports [8], [10], [22] Hybrid state data transfer Soft-state data transfer [6], [8], [19] Add-on security Inbuilt and integrated security [9], [10] End-to-end congestion control Congestion control at the source level [23] Interface naming Node naming [11] soft-state data transfer in terms of network performance and verifies its handshaking procedures. The application is run for certain time in each network and the network performance is observed for control and data sensing operations. ...
Full-text available
Internet of things (IoT) is one of the leading technologies which spanned from the trivial consumer applications to time-critical industrial applications. The current research in IoT focuses mostly on network performance as it is experiencing bottlenecks in data communication. IoT communication preferred UDP due to the limitations of TCP hard-state handshaking procedures on throughput. Proposed work developed a prototype with IoT devices communicating on a new internet architecture i.e. recursive inter-networking architecture (RINA) which has eliminated hard-state handshaking procedures. The impact of RINA on the network performance in process control and data acquisition is observed in terms of latency variations, network jitter and throughput. The results were compared against the network performance when the proposed prototype was communicating on TCP/IP. A Comparative analysis was provided to identify the improved network performance in RINA. This prototype was implemented in closed network configurations like LAN and WLAN in RINA as well as TCP/IP.
... The proposed model meets the specific requirements of IoT devices in terms of performance, scalability, and operability as the design has been implemented using FIWARE. Ramezanifarkhani and Teymoori in [42] proposed RINA approach that can address the architectural security challenges of IoT. The security and performance aspects in network architecture can be improved with RINA. ...
... Protocol Designs for Security PPKP-CBF (2011) [38] Using polynomial-based pair-wise key pre-distribution for intrusion detection BICLP-IDID (2012) [38] Using bio-inspired algorithms in cross layer protocol for intrusion detection WSDT-IDS (2014) [40] Using algorithm inspired by web spider for intrusion detection IAACaaS (2017) [41] Using OAuth 2.0 protocol for authorization RINA (2018) [42] Using inter network architecture for address security challenge IoT-Flows (2019) [43] Using Monitor, Analyse, Plan, Execute, and Knowledge for defense mechanism rmation 2021, 12, x FOR PEER REVIEW 19 of 22 Energy harvesting can be the solution for the energy constraint and makes it possible for the continuous operation of an IoT system. It can be observed that the protocol designs to support this energy harvesting activity are mostly for the MAC layer. ...
Full-text available
The autonomic Internet of Things is the creation of self-management capability in the Internet of Things system by embedding some autonomic properties, with the goal of freeing humans from all detail of the operation and management of the system. At same time, this provides a system to always operate on the best performance. This paper presents a review of the recent studies related to the design of network communication protocol, which can support autonomic Internet of Things. Many of the studies come from the research and development in Wireless Sensor Network protocols, as it becomes one of the key technologies for the Internet of Things. The identified autonomic properties are self-organization, self-optimization, and self-protection. We review some protocols with the objective of energy consumption reduction and energy harvesting awareness, as it can support the self-energy-awareness property. As the result, the protocol designs are mapped according to each autonomic property supported, including protocols for MAC layer, protocols for clustering, protocols for routing, and protocols for security. This can be used to map the advances of communication protocol research for the autonomic Internet of Things and to identify the opportunities for future research.
... Ramezanifarkhani et al. develop a survey [51] on how RINA addresses IoT challenges. They focuses on protocol stacking, repeated network functions in different layers, addressing, security, and attack mitigation. ...
Full-text available
The Internet of Things (IoT) and its current IETF and IEEE dual stack model have been facing limitations, requiring applications to overcome tough constraints by their own, narrowing the full potential of this concept. For instance, the IoT dual stack model does not entirely address or support perennial naming, immutable data provenance, data accountability, mobility support, and services’ self-organization. On the other hand, Future Internet Architecture (FIA) research emerges as a viable candidate to compensate these gaps through evolutionary and revolutionary efforts. Regardless the FIA proposal model, this field lacks a suitable environment that enables the performance experimentation and evaluation of distinct protocols and architectures fairly and transparently. This article proposes a novel IoT experimentation and evaluation environment based on a low-cost and open-source solution. The proposed environment integrates technologies of containers, IoT nodes emulation, and network simulation to evaluate the current IoT dual stack and a promising FIA approach called XIA. Moreover, this work combines the mentioned disjointed technologies, exploiting Docker containers, Contiki open-source operational system for IoT, and Cooja the IoT network simulator. In this way, it addresses the objective of fostering an honest experimentation and evaluation environment for FIAs. Experimental results demonstrate the feasibility and effectiveness of this approach, broadening this field and sowing a path to work with other FIAs.
... Any crisis always involves complex, uncertain, and unstable events and it is unpredictable and sudden. Moreover, crisis in complicated communities such as smart infrastructures becomes an over-increasing challenge [3]; one of the main challenges is an urgent need to tackle critical situations such as security attacks and their effects on the whole system. Existing products are generally not homogeneous, and they are hardly able to make right decisions in such situations [4]. ...
Full-text available
Previously, we have proposed a computational model for decision-making in crisis situations called C-RPD (Computational Recognition Primed Decision). In this paper, a software development process customized for Crisis Situations Decision-Making Systems (CSDMSs) is proposed. Agile processes can skillfully manage uncertainty in software requirements and some of their features like incremental development can solve some problems in developing CSDMSs. However, these processes do not provide comprehensive solutions for issues like the lack of enough knowledge about CSDMSs, very rapid changes, urgent need to overcome security challenges, high development unpredictability, and the performance test. Extreme Programming (XP) is one of the best and most widely-used agile processes. In this article, a customized version of XP called Crisis Situations Decision-Making Systems Software Development Process (CSDP) is proposed. Standing first and second in five national and international RoboCup rescue agent simulation tournaments from 2006 to 2010 bear witness to the efficiency of the developed software using CSDP. Relying on its characteristics, CSDP has been able to practically tackle the challenges of developing CSDMSs such as the lack of crisis-related knowledge and cumulative nature of crisis-related knowledge, difficulty of extracting knowledge, long development cycle, and sudden and frequent changes in system requirements.
The ever-increasing dependency of the utilities on networking brought several cyber vulnerabilities and burdened them with dynamic networking demands like QoS, multihoming, and mobility. As the existing network was designed without security in context, it poses several limitations in mitigating the unwanted cyber threats and struggling to provide an integrated solution for the novel networking demands. These limitations resulted in the design and deployment of various add-on protocols that made the existing network architecture a patchy and complex network. The proposed work introduces one of the future internet architectures, which seem to provide abilities to mitigate the above limitations. Recursive internetworking architecture (RINA) is one of the future internets and appears to be a reliable solution with its promising design features. RINA extended inter-process communication to distributed inter-process communication and combined it with recursion. RINA offered unique inbuilt security and the ability to meet novel networking demands with its design. It has also provided integration methods to make use of the existing network infrastructure. The present work reviews the unique architecture, abilities, and adaptability of RINA based on various research works of RINA. The contribution of this article is to expose the potential of RINA in achieving efficient networking solutions among academia and industry.
Full-text available
The Advent of Internet of Things (IoT) crowded the internet like never before. Ever-increasing connectivity brought many network vulnerabilities and caused many Cyber-attacks. The existing network stack is unable to avoid these casualties even though there are several security protocols. The present work aims to provide a secure network architecture that addresses almost all the network flaws in the existing network stack. It is based on Recursive Internetworking architecture (RINA) which is a promising solution being developed by researchers from a couple of decades. The features and capabilities of RINA architecture can replace existing communication technology with better security. The proposed method is developed with RINA architecture in closed environment like LAN. It verifies RINA features that prevent network flow attacks effectively.
Full-text available
We claim to have identified gaps between threat modeling frameworks, threat model use in IoT security research and attacks that may be missed by current research. While security research includes sections known as ‘threat models’, these models are not supported by the categorization and standardization that threat modeling frameworks would have to offer. Then again, if existing threat modeling frameworks were used, they would still allow many vulnerabilities to pass through undetected, since they are meant for software-only projects. This work will explain the origins of IoT research, enumerate common threat modeling frameworks and give an insight into the state of IoT security research. In the course of this, it will become clear how these gaps came to be and what research directions would help to close them.
Full-text available
Internet of Things (IoT) are everywhere in our daily life. They are used in our homes, in hospitals, deployed outside to control and report the changes in environment, prevent fires, and many more beneficial functionality. However, all those benefits can come of huge risks of privacy loss and security issues. To secure the IoT devices, many research works have been conducted to countermeasure those problems and find a better way to eliminate those risks, or at least minimize their effects on the user's privacy and security requirements. The survey consists of four segments. The first segment will explore the most relevant limitations of IoT devices and their solutions. The second one will present the classification of IoT attacks. The next segment will focus on the mechanisms and architectures for authentication and access control. The last segment will analyze the security issues in different layers.
Full-text available
The Internet of things (IoT) has recently become an important research topic because it integrates various sensors and objects to communicate directly with one another without human intervention. The requirements for the large-scale deployment of the IoT are rapidly increasing with a major security concern. This study focuses on the state-of-the-art IoT security threats and vulnerabilities by conducting an extensive survey of existing works in the area of IoT security. The taxonomy of the current security threats in the contexts of application, architecture, and communication is presented. This study also compares possible security threats in the IoT. We discuss the IoT security scenario and provide an analysis of the possible attacks. Open research issues and security implementation challenges in IoT security are described as well. This study aims to serve as a useful manual of existing security threats and vulnerabilities of the IoT heterogeneous environment and proposes possible solutions for improving the IoT security architecture.
The Internet of things (IoT) has recently become an important research topic because it integrates various sensors and objects to communicate directly with one another without human intervention. The requirements for the large-scale deployment of the IoT are rapidly increasing with a major security concern. This study focuses on the state-of-the-art IoT security threats and vulnerabilities by conducting an extensive survey of existing works in the area of IoT security. The taxonomy of the current security threats in the contexts of application, architecture, and communication is presented. This study also compares possible security threats in the IoT. We discuss the IoT security scenario and provide an analysis of the possible attacks. Open research issues and security implementation challenges in IoT security are described as well. This study aims to serve as a useful manual of existing security threats and vulnerabilities of the IoT heterogeneous environment and proposes possible solutions for improving the IoT security architecture.
Fog/edge computing has been proposed to be integrated with Internet-of-Things (IoT) to enable computing services devices deployed at network edge, aiming to improve the user’s experience and resilience of the services in case of failures. With the advantage of distributed architecture and close to end-users, fog/edge computing can provide faster response and greater quality of service for IoT applications. Thus, fog/edge computing-based IoT becomes future infrastructure on IoT development. To develop fog/edge computing-based IoT infrastructure, the architecture, enabling techniques, and issues related to IoT should be investigated first, and then the integration of fog/edge computing and IoT should be explored. To this end, this paper conducts a comprehensive overview of IoT with respect to system architecture, enabling technologies, security and privacy issues, and present the integration of fog/edge computing and IoT, and applications. Particularly, this paper first explores the relationship between Cyber-Physical Systems (CPS) and IoT, both of which play important roles in realizing an intelligent cyber-physical world. Then, existing architectures, enabling technologies, and security and privacy issues in IoT are presented to enhance the understanding of the state of the art IoT development. To investigate the fog/edge computing-based IoT, this paper also investigate the relationship between IoT and fog/edge computing, and discuss issues in fog/edge computing-based IoT. Finally, several applications, including the smart grid, smart transportation, and smart cities, are presented to demonstrate how fog/edge computing-based IoT to be implemented in real-world applications
Conference Paper
With the proliferation of cloud computing and the expected requirements of future Internet of Things (IoT) and 5G network scenarios, more efficient and scalable Data Centers (DCs) will be required, offering very large pools of computational resources and storage capacity cost-effectively. Looking at todays’ commercial DCs, they tend to rely on well-defined leaf-spine Data Center Network (DCN) topologies that not only offer low latency and high bisectional bandwidth, but also enhanced reliability against multiple failures. However, routing and forwarding solutions in such DCNs are typically based on IP, thus suffering from its limited routing scalability. In this work, we quantitatively evaluate the benefits that the Recursive InterNetwork Architecture (RINA) can bring into commercial DCNs. To this goal, we propose rule-based topological routing and forwarding policies tailored to the characteristics of publicly available Google’s and Facebook’s DCNs. These policies can be programmed in a RINA-enabled environment, enabling fast forwarding decisions in most scenarios with merely neighboring node information. Upon DCN failures, invalid forwarding rules are overwritten by exceptions. Numerical results show that the scalability of our proposal depends on the number of concurrent failures in the DCN rather than its size (e.g., number of nodes/links), dramatically reducing the total amount of routing and forwarding information to be stored at nodes. Furthermore, as routing information is only disseminated upon failures across the DCN, the associated communication cost of our proposals largely outperforms that of the traditional IP-based solutions.