SDN Enabled Secure IoT Architecture

Kallol Krishna Karmakar∗ , Vijay Varadharajan∗ , Surya Nepal† , Uday Tupakula∗ ,

∗ AdvancedCyber Security Engineering Research Centre
The University of Newcastle, Australia -2308
† Data 61, CSIRO,
Australia, Marsfield NSW 2122
[email protected]∗ ,[vijay.varadharajan,uday.tupakula]@newcastle.edu.au∗ ,[email protected]†

Abstract—The Internet of Things (IoT) is increasingly being used (DoS) and energy depletion attacks are the most common IoT
in applications ranging from precision agriculture to critical attacks [6, 7]. Often it is not possible to implement security
national infrastructure by deploying a large number of resource- on these devices using traditional defence mechanisms as they
constrained devices in hostile environments. These devices are
being exploited to launch attacks in cyber systems. As a result, are located in open environments and they would incur extra
security has become a significant concern in the design of computational load on small IoT devices. One main issue is
IoT based applications. In this paper, we present a security how to ensure that only authenticated data from legitimate IoT
architecture for IoT networks by leveraging the underlying devices is used in cloud processing and in service provision. In
features supported by Software Defined Networks (SDN). Our this paper, we develop a network based architecture solution
security architecture restricts network access to authenticated
IoT devices. We use fine granular policies to secure the flows in that can help to secure the IoT infrastructure. The main idea
the IoT network infrastructure and provide a lightweight protocol behind our solution is that it enables only authenticated data
to authenticate IoT devices. Such an integrated security approach from legitimate IoT devices that are able to discover and use
involving authentication of IoT devices and enabling authorized the network services, as well as enabling only the authorized,
flows can help to protect IoT networks from malicious IoT devices network services to consume data only from authenticated
and attacks.
devices.
Index Terms—Internet of Things (IoT) Security, Software Defined
Network (SDN) Security, Policy based Secure IoT Architecture, Our security architecture makes use of Software Defined
IoT Authentication and Access Control. Networks (SDN) to manage the IoT infrastructures securely.
In SDN infrastructure, the Controller has visibility over its
I. I NTRODUCTION network domain, the applications running in the Controller can
manage the security of the underlying IoT network infrastruc-
The Internet of Things (IoT) is being touted as the next big ture. The use of SDN to manage the IoT devices is not in
technological trend by both academic researchers and industry itself new; other works [8, 9] have used such an approach to
players. The IoT refers to the connection of ‘things’ in the real detect malicious devices and detect attacks. However, in our
world via the Internet, so that these ‘things’ can communicate architecture, SDN Controller acts as a security policy decision
with each other as well as other Internet services. Examples authority, and the network switches and IoT gateways enforce
of devices range from smart light bulbs, to door locks, to the security policies in the IoT network infrastructure. Such
traffic sensors, to baby monitors and healthcare devices. These a policy-driven approach provides the capability to achieve
IoT devices can be small and resource constrained as well as secure management of network flows in an IoT infrastructure
embedded in other real world objects. According to an industry in a dynamic manner, and deal with security attacks in a
estimate, the number of IoT devices is expected to reach 50 proactive manner.
billion by 2020 [1]. IoT enables the connection of the physical In this paper, we describe a policy-driven security architecture
world with the cyber world, allowing remote monitoring and using SDN for an IoT network infrastructure. The security
control of physical objects from the cyber world [2, 3]. The architecture uses fine grained policies to control and manage
heterogeneity of the IoT devices, underlying communication services and IoT devices as well as secure the corresponding
infrastructure and the different types of protocols used by these flows in the IoT infrastructure. For instance, policies can
devices increase the complexity of the IoT infrastructure and enforce the creation of secure channels for data from particular
make it vulnerable to security attacks. As has been the case authenticated IoT devices through specific gateways to the
with the Internet, security has become an after-thought, and cloud. This can help to achieve secure flow management in
many IoT devices and applications are already in operation the IoT network infrastructure. Our security architecture also
without any security mechanism. A major challenge is how to provides device authentication and data integrity enabled IoT
provide security in such IoT infrastructures [4, 5]. services as well as device authorization for network services. A
Due to the resource constrained nature of IoT devices, an at- lightweight elliptic curve cryptography (ECC) based protocol
tacker is able to target them easily by sending forged requests, has been deployed to achieve authentication of IoT devices
intercepting and illegally manipulating valuable sensor data in and integrity of IoT data. Authorization for network services
transit or capturing a physical device and transforming it to a requested by different IoT devices is achieved using Open Au-
zombie to launch attacks on other systems. Denial of service thorization (OAuth) protocol [10]. The proposed architecture
978-3-903176-15-7
c 2019 IFIP has been implemented using ONOS SDN Controller.

581
The rest of the paper is structured as follows. Section II gives A. Security Architecture for IoT Network Infrastructure
an overview of IoT infrastructure. Section III describes the Our proposed SDN based security architecture uses policies to
SDN based security architecture for IoT infrastructure. Finally, control and manage IoT devices, services and network entities
Section IV concludes the paper. (switches, nodes and gateways). Figure 1 shows the proposed
SDN based security architecture. The heart of the security
II. I NTERNET OF T HINGS (I OT)
architecture is the SDN Controller where security policies
In this section, we give a summary of the different layers in an reside and are evaluated. The IoT actuators and sensors are
IoT architecture and also explain why we have chosen SDN the end devices and connect to the IoT Nodes. These IoT
infrastructure for managing IoT network. Nodes are connected to the IoT Gateways either via wired
or wireless networks. The IoT Gateways are connected to
A. IoT Infrastructure: the SDN Controller. In some cases, OpenFlow switches can
An IoT infrastructure can be thought of as consisting of four act as IoT Gateways/Nodes. Our implementation considers
architecture layers, namely Perception, Network, Middleware OpenFlow switches as IoT Gateways. Users are connected to
and Application Layers [11]. The Perception Layer acts as an the OpenFlow switches.
interface to the physical world and consists of actuators and The IoT devices are of a heterogeneous nature. The IoT
sensors. This layer transfers the raw data to the Network Layer. devices can use different network protocols, authentication
The Network Layer processes and routes the data through the mechanism, can have different operation and application plat-
network infrastructure. Further processing of the data happens forms. Furthermore, there can be a large number of IoT
at the Middleware Layer. This layer helps to perform actions devices. Hence, a scalable solution is needed, recognizing the
pre-encoded by third-party applications running on the Ap- individual capabilities of the connected IoT devices. In our
plication Layer. The Application Layer provides the interface security architecture, we have created a device provisioning
for third-parties to develop and execute their applications for mechanism for each IoT device groups using a template
storage and further processing of the device data. based approach. Each template consists of variables explaining
device capabilities like protocol, manufacturer, authentication
B. Why SDN for IoT Security? mechanisms and other features. This device provisioning
The features of SDN technology which make it a suitable functionality is integrated with the core application of the
platform for securing IoT infrastructure are as follows: Controller, enabling it to provision the IoT devices at runtime.
Separation of Control Plane from Data Plane: This is useful In our implementation, we have developed two secure applica-
for designing our policy based security architecture at the tions that control and manage the behaviour of IoT devices in
SDN Controller in the control plane and enforcing the security the network. These applications runs over an SDN Controller.
policies in the network switches and IoT devices in the data The first one is the Policy based Security Application (PbSA),
plane. The SDN Controller communicates with the switches and the second one is called IoT Security Applications (ISA).
in the data plane using open and standardised interfaces ISA has two sub-modules, namely IoT Authentication Authority
and protocols (OpenFlow), which is useful for securing the and IoT Authorization Authority. Before describing in detail
communications between the policy decision authority in the the functions of each of these applications and modules, we
Controller and the enforcement mechanisms in the IoT devices first provide a high-level overview of the security interactions
and switches. with the IoT devices in the network infrastructure.
Network Domain View: The SDN Controller has visibility The operation of our security architecture can be viewed as
over the whole network domain under its jurisdiction. This involving two phases. In the first phase, we have interactions
can be used by our architecture to achieve secure management that are associated with authentication. New IoT devices that
of IoT devices and flows in the network infrastructure. The are to be connected to the network need to be authenticated.
Controller maintains a topological information database which IoT Gateways forward IoT device information (such as device
logs information about all the forwarding devices connected ID) using Packet in messages to the SDN Controller. The IoT
to the Controller. This will be useful in the specification of Authentication Authority module in the ISA application carries
path based security policies in our architecture. out the authentication process using a lightweight elliptic
SDN Northbound Applications: The SDN provides flexible curve cryptography (ECC) based authentication protocol. This
northbound API which enables us to develop secure applica- process of IoT authentication will in turn make the network
tions or use third-party applications to securely monitor and domain and services visible to authenticated IoT Devices.
control the behaviour of IoT devices and network nodes in the In the second phase, the PbSA checks the network service
SDN network domain. Our security architecture has a secure request from authenticated IoT devices against the specified
application running on top of the Controller (developed using security policies. The PbSA has fine grained policies that
its northbound API) that provides security services in the IoT control the behaviour of the IoT devices; for instance, a user
infrastructure. “A” accessing via OpenFlow Switch 3 (SW3) is allowed to
read data from Sensor 2 connected through Gateway I (SW1
III. SDN BASED S ECURITY A RCHITECTURE FOR I OT & Node NII). We describe the security policies and their
N ETWORK I NFRASTRUCTURE implementation in detail in Section III-B. If the service request
We use Software Defined Networks (SDN) to develop our is permissible according to PbSA security policies, then our
security architecture for IoT network infrastructure. security architecture uses the OAuth protocol to provide a

582 2019 IFIP/IEEE International Symposium on Integrated Network Management (IM2019): Poster Sessions
 Developed Security Applications

IoT Authorization 
Evaluation  Authority
Enforcer Repositories 
Engine  Other Network Applications

PbSA
IoT Authentication 
Authority
Policy Manager
IoT Security Application 

NorthBound Interface

SDN Core Applications and Modules  

SouthBound Interface (Forwarding Devices)
SW1 SW2 SW3 SW4

OpenFlow Swithces
GWI  GWII
User A User D
IoT Gateways

NI NII NI NII User B User C User E User F

IoT Nodes

Sensors/Actuators
*GW‐ IoT Gateway
*N‐IoT Node 
*PbSA‐ Policy based Security Application

Fig. 1: Security Architecture for IoT Network Infrastructure

token to the IoT device. The IoT device uses this token for associated with the OpenFlow IoT Gateways.
further communication in the network. This process is jointly • Policy Enforcer: Fetches the required information from
performed by PbSA and IoT Authorization Authority. the OpenFlow IoT Gateways and enforces the flow rules
obtained from the Policy Manager.
B. Policy Based Security Architecture
Security Policy
Our IoT network infrastructure consists of OpenFlow switches/ The security policies are expressed as Policy Expressions (PE),
IoT Gateways and end hosts (IoT sensors/ actuators). We have which specify whether packets and flows from IoT devices and
used a single SDN Controller to manage the IoT network end hosts follow a particular path or paths in the network, and
infrastructure. The network devices (OF devices) forward the the conditions under which the packets and flows follow these
packets generated by the IoT devices/ users, which are then paths. The PE syntax uses an enhanced version of RFC1102
subjected to the policies specified in the SDN Controller [12]. They are fine-grained and specify a range of policies
for transfer in the network. Figure 1 shows the Policy-based using various attributes of IoT devices and flows; for instance,
Security Architecture (PbSA) for securing the IoT Infrastruc- these attributes include different types of devices, source and
ture using SDN. As PbSA is designed to be modular, the destination attributes, flow attributes and constraints, requested
components of PbSA can be implemented on a single host services, security services and security labels. The attributes
or can be distributed over multiple hosts. Here, we provide a are: (a) Flow Attributes: Flow ID, sequence of packets associ-
detailed description of different modules of PbSA. ated with the Flow, type of packets, Security Profile indicating
PbSA consists of four major modules, namely a) Policy the set of security services that are to be associated with the
Manager, b) Evaluation Engine, c) Repositories & d) Policy packets in the Flow; (b) Device Attributes: ID specific to
Enforcer. IoT sensor/actuator; (c) Switch Attributes: Identities of the
• Policy Manager: It is the core component of the security Switches and Security Label of the Switches (In our case,
architecture, as it manages every operation such as extracts these are OpenFlow IoT Gateways); (d) Host Attributes:
IoT device flow attributes, updates the Topology Repository, Identities of Hosts such as Source/Destination Host ID; (e)
and instructs the Policy Enforcer to enforce the policies at Flow and Domain Constraints: Constraints such as Flow
the OpenFlow IoT Gateways. It also communicates with Constraints (FlowCons) and Domain Constraints (DomCons)
the ISA application for the transfer of OAuth token after associated with a specific device Flow; (f) Services: For which
checking the network service request from the IoT devices. the PE applies (e.g. FTP storage access); (g) Time Validity:
• Evaluation Engine: It evaluates the service request against The period for which the PE remains valid; and (h) Path:
the relevant policies stored in the Policy Repository. Indicates a specific sequence of switches any particular flow
• Repositories: Our architecture has two repositories: a) from specific IoT devices/users should traverse.
Topology Repository and b) Policy Repository. The Topol- The Constraints (Flow and Domain) are conditions that ap-
ogy Repository contains the network topology of IoT de- ply to specific flows from any IoT devices. For instance,
vices and end hosts/users. SDN controller has its own device a constraint might specify the flow from a specific type of
Topology Repository. We are using the same Topology sensor, should only go through a set of switches that can
Repository for this purpose. The Policy Repository contains provide a gurrented bandwidth. From a security point of view,
the Policy Expressions (PE) associated with the various IoT a constraint could be that a flow should only go through
devices and the associated flow attributes. The attributes in OpenFlow switches that have a particular Security Label. The
PEs also include security parameters such as security labels PEs support wildcards for attributes, enabling it to set policies

2019 IFIP/IEEE International Symposium on Integrated Network Management (IM2019): Poster Sessions 583
for a group of IoTs/services. A simplified Policy Expression Algorithm 1 below gives an outline of the 3 stages. The
template is as follows: Key Agreement (Stage 3) is illustrated in Figure 3. The
performance of the proposed protocol (in terms of both com-
P Ei = < F lowID, IoT DeviceID, SourceAS, DestAS, putation and communication costs) is lower than the previously
SourceHostIP, DestHostIP, SourceM AC, DestM AC, proposed protocols. Hence it is particularly suitable for the IoT
U ser, F lowCons, DomCons, Services, Sec − P rof ile, environment as it shifts the processing load from the resource-
Seq − P ath >:< Actions > limited devices to the more powerful servers in the Controller.
where i is the Policy Expression number.

Algorithm 1: ECC Protocol

C. IoT Security Application (ISA)
1 Step1 (Setup): a) The IoT Authentication Authority
In this section, we briefly explain the security protocols used
chooses a prime number q, computes Fq , E/Fq , Gq , P ;
in our security architecture. These are implemented by the IoT
b) The IoT Authentication Authority chooses a master
Security Application (ISA).
key x and calculates public key Ppub = xP ∈ E/Fq ;
In our architecture, each IoT device has a unique ID and
c) It then computes two hashes H1 and H2;
connects to IoT Gateways using wireless networks. The IoT
d) Fq , E/Fq , Gq , P, Ppub , H1, H2 are made public.;
Gateways are basically OpenFlow Switches/ Access Points
2 Step2 (Installation): IoT Authentication Authority and
(OF-AP) which support OpenFlow protocol. As mentioned
devices separately generate and validate their private
earlier, our security protocol has two phases, namely the
and public keys.;
authentication phase followed by the policy application and
Rgt = rgt P , where rgt is a random number rgt ∈ Zq∗ .
the OAuth protocol phase.
ygt = H1 (IDgt , Rgt ).x
IoT devices are authenticated in the first phase of the se-
Rd = rd P , where r is a random number ri ∈ Zq∗ .
curity protocol. We have used a lightweight ECC protocol
yd = H2 (IDd , ygt ).x
[13] to authenticate the IoT devices. An IoT device sends
Sd = rd + yd
a “Hello” message with its ID (Message X in Figure 2)
Sd and Rd are the private and public values of d.
requesting for a Network Service (NS). The OF-APs sends
At the end of this stage each device has its own
the ID and Network Service (NS) request via P acket in mes-
Sd , Rd , yd , rd and IoT Authentication Authority has
sages to the IoT Authentication Authority. IoT Authentication
(ygt , rgt );
Authority performs authentication of the IoT devices using
3 Step3 (Key Agreement): Between IoT Authentication
ECC based protocol. At the end of the authentication phase,
Authority and IoT Devices;
IoT Authentication Authority authenticates the IoT device and
establishes a common secret key with the IoT device that can
be used for further secure communications. In [13], the authors analyze the security of the ECC authentica-
In the authorization phase, the PbSA checks the Network tion scheme and show that it is secure against active attackers
Service (NS) request from the IoT device using the security who are capable of eavesdropping, modifying and injecting
policy specifications described above. The IoT Authentication messages in the protocol.
Authority uses the key established by the ECC protocol in the Authorization for Network Services using OAuth Protocol
authorization request to PbSA. If the device and flow attributes The authorization service using the OAuth protocol [10, 14]
for the Network Service (NS) satisfy the Policy Expressions, works as follows: It consists of four actors: i) Client, ii)
then the PbSA requests the IoT Authorization Authority to Resource Owner, iii) Resource Server and iv) Authorization
generate the OAuth Token for the particular IoT device for Server. The client contacts the Resource Owner of the re-
the specific Network Service(s) requested. The token is then source. The Resource Owner grants the access to the client by
used by the authenticated IoT device to access the required sending an authorization code. The client delivers the received
Network Service(s). This process is illustrated in Figure 2. authorization code to the Authorization Server. The Autho-
Lightweight ECC based Authentication for IoT Devices rization Server verifies the authorization code and releases a
The Elliptic Curve Cryptography (ECC) based public key token containing the details of the consent provided to the
system uses the algebraic structure of elliptic curves as their client (time limit, scope, and so on). The client forwards the
finite points. It is computationally faster than other public token to the Resource Server. The Resource Server checks
key cryptosystems such as RSA. Hence it is more suitable the validity of the received token, and in the affirmative case
for computationally constrained IoT devices. It can be used provides access to the protected resource.
to achieve key agreement as well as encryption and digital In our SDN-IoT architecture, network services are the re-
signature. In our security architecture, the IoT devices are sources. Figure 2 shows the OAuth Token handover process
authenticated using a lightweight ECC based authentication (marked with a continuous green line). First, the IoT Authen-
protocol proposed in [13]. Then we use the key established tication Authority authenticates the IoT devices using ECC
using this protocol to encrypt the data from the authenticated protocol mentioned above. After the authentication phase, it
IoT devices. This lightweight security protocol works in requests access to network services on behalf of the authen-
conjunction with the OAuth protocol. ticated IoT devices. The PbSA checks the policy repository
The ECC based authentication protocol used in our architec- and if the network service request is valid, then it issues
ture has 3 stages: Setup, Installation and Key Agreement. an Authorization Permission (Kp), which is forwarded to the

584 2019 IFIP/IEEE International Symposium on Integrated Network Management (IM2019): Poster Sessions
 IoT Authorization  IoT Authentication 
Device Gateways/OF AP PbSA
Authority Authority
S0: X= ID+Hello+ NS
S1: Packet_IN(X)

Generates a Є Zq*, S2: Initiate ECC device authentication procedure 
Td= aP
S3: Send (IDd, Td, Rd)

Kgt‐>gt=(Sgt+a)Tgt;
M’=H1(0,kd‐>gt); S4: Send (Tgt, M1)
Check M’==M1;
If valid set
K=H1(IDd||IDgt, kd‐>gt);
M2=H1(1, kd‐>gt) M’’=H1(1, Kgt‐>d);
S5: Send (M2)
Checks M2==M’’;
If valid then set 
Checks Policy 
K=H1(IDd||IDgt,kgt‐>d)
Expression for 
S6: Request for  accessing Network 
Network Service (NS) Services (NS)
 Authorization(K) If ok then provides
Generates OAuth  S7: Authorization  Authorization 
Token (Ko) Permission(Kp) Permission

S8: Send Authorization 
Token (Ko)

ECC procedure
OAuth procedure

Fig. 2: Security Protocol process diagram

Device  IoT Authentication Authority
Calculates:  ∗
;  network access and connections between allowed elements
  , , →  Calculates:  ∗ ; 
;  using a software controlled architecture [15]. Our SDN-IoT
; 
;  ← ,   , ; 
security architecture allows communication for IoT devices
⇒ ⇒
, ⇒ ;  , ⟹ ;  that have been authenticated (IoT Authentication Authority)
Checks  ; 
If valid set,  and whose requests for network services are authorized against
  ∥ , ; 
, ⇒
⇒
  →  ,
a set of policies specified in our PbSA which determines
⇒ ; 
Checks  ;  whether the security constraints have been met. The separation
If valid then set 
∥ , ⇒  
between control and data planes has been achieved using
the SDN architecture whereby the ability to control access
Fig. 3: Key agreements between Devices and IoT Authentica- is managed separately from the transmission of data and the
tion Authority communications between the IoT devices are virtualised using
overlays that represent logical paths over a physical network.
IoT Authorization Authority. The IoT Authorization Authority
We believe such a combination of SDN based policy-driven
generates the OAuth Token (Ko). We have used JSON Web
security architecture together with lightweight authentication
Token (JWT) for this purpose. The IoT Authorization Authority
protocol and OAuth authorization framework offers a novel
forwards the OAuth Token to the IoT devices. The OAuth
approach for secure provision and management of services in
Token (Ko) contains the user ID, IoT device ID, device type
an IoT network infrastructure.
(e.g. sensor or actuator) and expiry time (network service
access time). The IoT device integrates this OAuth Token in R EFERENCES
their network packet while accessing the network services. [1] R. Bogue, “Towards the trillion sensors market,” Sensor Review, vol. 34, no. 2, pp.
137–142, 2014.
In our current implementation, we have signed the OAuth [2] J. Gubbi et al., “Internet of things: A vision, architectural elements, and future
Token using the private key of IoT Authentication Authority directions,” Future generation computer systems, vol. 29-7, pp. 1645–1660, 2013.
[3] S. D. T. Kelly et al., “Towards the implementation of iot for environmental condition
Sg t, which was used in the ECC authentication phase. The monitoring in homes,” IEEE Sensors Journal, vol. 13, no. 10, pp. 3846–3853, 2013.
signature is verified by the network service using the public [4] R. H. Weber, “Internet of things–new security and privacy challenges,” Computer
law & security review, vol. 26, no. 1, pp. 23–30, 2010.
key of IoT Authentication Authority Rg t before service pro- [5] M. Medwed, “Iot security challenges and ways forward,” in Proceedings of the 6th
vision. (In a more general distributed architecture where IoT International Workshop on Trustworthy Embedded Devices. ACM, 2016, p. 55.
[6] L. A. B. Pacheco et al., “Evaluation of distributed denial of service threat in the
Authorization Authority and IoT Authentication Authority are internet of things,” in Network Computing and Applications (NCA), 2016 IEEE
not co-located, the ECC authentication protocol will be used 15th International Symposium on. IEEE, 2016, pp. 89–92.
[7] X. Cao et al., “Ghost-in-zigbee: Energy depletion attack on zigbee-based wireless
to generate public and private values for IoT Authorization networks,” IEEE Internet of Things Journal, vol. 3, no. 5, pp. 816–829, 2016.
Authority using a similar process as for an IoT device and this [8] M. Miettinen et al., “Iot sentinel: Automated device-type identification for security
enforcement in iot,” in Distributed Computing Systems (ICDCS), 2017 IEEE 37th
private key will be used to sign the OAuth Token). International Conference on. IEEE, 2017, pp. 2177–2184.
[9] L. Galluccio et al., “Sdn-wise: Design, prototyping and experimentation of a
stateful sdn solution for wireless sensor networks,” in Computer Communications
IV. C ONCLUSION (INFOCOM), 2015 IEEE Conference on. IEEE, 2015, pp. 513–521.
[10] D. Hardt, “The oauth 2.0 authorization framework,” 2012.
Threats towards the IoT network infrastructure are increasing [11] L. Da Xu et al., “Internet of things in industries: A survey,” IEEE Transactions on
on a daily basis. Due to resource constraints and diversity of industrial informatics, vol. 10, no. 4, pp. 2233–2243, 2014.
[12] D. Clark, “Policy routing in internet protocols. request for comment rfc-1102,”
devices, it is hard to deploy existing legacy security measures Network Information Center, 1989.
in IoT networks. In this paper, we focused on proposing a [13] A. Mohammadali et al., “A novel identity-based key establishment method for
advanced metering infrastructure in smart grid,” IEEE Trans. on Smart Grid, 2016.
security solution for IoT network infrastructure. Our proposed [14] S. Sciancalepore et al., “Oauth-iot: An access control framework for the internet
security architecture uses SDN to provide authentication and of things based on open standards,” in Computers and Communications (ISCC),
2017 IEEE Symposium on. IEEE, 2017, pp. 676–681.
authorization services to IoT network infrastructure. Our pro- [15] D. Conde, “Software-defined perimeters: An architec-
posed security architecture aligns with the emerging Software tural view of sdp,” https://sdn.ieee.org/newsletter/march-2017/
software-defined-perimeters-an-architectural-view-of-sdp, March 2017.
Defined Perimeter (SDP) paradigm which aims to restrict

2019 IFIP/IEEE International Symposium on Integrated Network Management (IM2019): Poster Sessions 585