Securing RPL using Network Coding: The Chained Secure Mode (CSM)
IIEEE INTERNET OF THINGS, VOL. XX, NO. X, XXX 2021 1
Securing RPL using Network Coding: The ChainedSecure Mode (CSM)
Ahmed Raoof,
Student Member, IEEE,
Chung-Horng Lung,
Senior Member, IEEE, and Ashraf Matrawy,
Senior Member, IEEE
Abstract —As the de facto routing protocol for many Internet ofThings (IoT) networks nowadays, and to assure the confidentialityand integrity of its control messages, the Routing Protocol forLow Power and Lossy Networks (RPL) incorporates three modesof security: the Unsecured Mode (UM), Preinstalled Secure Mode(PSM), and the Authenticated Secure Mode (ASM). While thePSM and ASM are intended to protect against external routingattacks and some replay attacks (through an optional replayprotection mechanism), recent research showed that RPL in PSMis still vulnerable to many routing attacks, both internal andexternal. In this paper, we propose a novel secure mode for RPL,the Chained Secure Mode (CSM), based on the concept of intra-flow Network Coding (NC). The CSM is designed to enhanceRPL’s resilience and mitigation capability against replay attacks,while allowing the integration with external security measuressuch as Intrusion Detection Systems (IDSs). The security andperformance of the proposed CSM were evaluated and comparedagainst RPL in UM and PSM (with and without the optionalreplay protection) under several routing attacks: the Neighborattack (NA), Wormhole (WH), and CloneID attack (CA), usingaverage packet delivery rate (PDR), End-to-End (E2E) latency,and power consumption as metrics. It showed that CSM hasbetter performance and more enhanced security than both theUM and PSM with the replay protection, while mitigating boththe NA and WH attacks and significantly reducing the effect ofthe CA in the investigated scenarios.
Index Terms —IoT, Security and Privacy, Secure Routing, RPL,Routing Attacks, Chained Secure Mode, CSM.
I. I
NTRODUCTION
Made into a standard in 2012, Routing Protocol for LowPower and Lossy Networks (RPL) [1] has attracted a greatdeal of research interest. In particular, routing security inRPL was of special interest, including different routing attacksthe protocol is susceptible to [2]–[4], mitigation methods andIntrusion Detection Systems (IDSs) [5]–[7], and performanceevaluation of some of RPL’s security mechanisms [8]–[10].Our previous work [8], [9] showed that RPL’s securemodes, while providing reasonable mitigation of some externalattacks, are still vulnerable to many routing attacks (bothinternal and external) (see §IV-A), especially the replay attackssuch as Neighbor attack (NA) and Wormhole (WH) attack.This paper presents a significant extension to our previousconference paper [11], where we devised a proof-of-conceptprototype of Chained Secure Mode (CSM). In this work, Weadded a proper Secret Chaining (SC) recovery mechanism toCSM and the capability to integrate external security measures
A. Raoof and C. Lung are with the Department of Systems and ComputerEngineering, Faculty of Engineering and Design, Carleton University, Ottawa,ON, Canada (email: [email protected]; [email protected])A. Matrawy is with the School of Information Technology, CarletonUniversity, Ottawa, ON, Canada (email: [email protected]) (e.g., IDSs) into CSM. Then, a thorough evaluation of theimproved CSM was executed against the other RPL securemodes in the presence of several routing attacks - see §V.Our contributions can be summarized as follows: • A novel secure mode for RPL, the CSM, was designedand complemented with a proper recovery mechanismand integration capability with external security mech-anisms. The new secure mode uses the principle of intra-flow NC to create a linked chain of coded RPL controlmessages between every two neighboring nodes. Thechaining effect can limit adversaries’ ability to launchsome routing attacks, e.g., identity-cloning and replayattacks (e.g., WH and NA attacks) [2]. • A prototype of the proposed CSM was implemented inContiki Operating System (OS) [12], including the newly-added features mentioned above. • Using 350 simulation experiments, and to demonstrate thecapabilities of the CSM prototype, a security and perfor-mance comparison between RPL in CSM and PreinstalledSecure Mode (PSM) (with and without the optional replayprotection) against the NA, CloneID attack (CA), and WHattack was conducted using several metrics. • For the internal adversary cases, the results showed thatCSM is capable of mitigating both the NA and WH at-tacks with less latency ( ≈
95% less) and power consump-tion ( ≈ • For the external adversary cases, the results showed thatCSM is the only secure mode capable of mitigating theWH attack with PDR ≈ ELATED W ORKS
Perazzo et al. in [13] provided an implementation of PSMfor RPL, along with the optional replay protection, named theConsistency Check (CC) mechanism. Their work was basedon ContikiRPL (Contiki OS version of RPL). The authorsprovided an evaluation for their implementation, and compared
EEE INTERNET OF THINGS, VOL. XX, NO. X, XXX 2021 2
RPL’s performance between PSM and UM. However, It wasnoted that the replay protection mechanism introduced highernetwork formation time and increased power consumption. Anoptimized version of the replay protection mechanism wasintroduced in [10] that uses RPL options [1] to include anotherunique nonce value within the exchanged CC messages. Theevaluation of the optimized mechanism showed a 36% shorternetwork formation time and 45% decrease in the CC messagesexchanged while maintaining the same level of protection. Itwas shown in our work in [8] that, based on the authors’implementation, PSMrp is still vulnerable to replay attacks,specifically the WH attack where the adversaries will replaythe CC messages between the victim nodes.Airehrour et al. in [14] proposed a modified version of RPL,named
SecTrust-RPL . The authors used their devised SecTrustframework [15], where the optimum route is chosen based onthe trust evaluation of the nodes, resulting in isolating sus-pected adversaries. Trust is calculated based on the successfulpacket exchange between the nodes, and it is dependent ontime.
SecTrust-RPL was evaluated under the Decreased Rankand Sybil attacks using Contiki OS in both simulation and areal testbed. Compared to RPL in UM under the same attacks,
SecTrust-RPL showed a significant decrease in lost packets( ≈ RIEF O VERVIEW
As a distance-vector routing protocol, RPL arranges thenetwork devices into a Destination Oriented Directed AcyclicGraph (DODAG) [16]: a network of nodes connected withoutloops with the traffic directed toward one root node [1],[17]. The creation of DODAGs and how parents are selecteddepends on two aspects: the
Objective Function (OF) , whichdefines the used RPL configurations, and the node’s rank .The DODAG in RPL is built by exchanging control mes-sages. These control messages have five types; four of themhave two versions (base and secure versions), and the last onehas only a secure version. When enabling any of the securemodes of RPL (explained later in this section), the controlmessages are switched to their secure versions, which add newunencrypted header fields and either a Message AuthenticationCode (MAC) or a digital signature field to the end of the baseversion, then encrypts the base part and the MAC/signaturefield [1]. All RPL messages are sent as Internet ControlMessage Protocol (ICMPv6) messages, with the " Type " field inits header equal to 155 – as set by Internet Assigned NumbersAuthority (IANA) – and the "
Code " field identifying the typeof the RPL control message [1].The five types of RPL control messages go as follows [1]:DODAG Information Object (DIO) and DODAG InformationSolicitation (DIS) messages are used for the creation and main-tenance of the upward DODAG, while the Destination Adver-tisement Object (DAO) / DAO Acknowledgement (DAO-ACK)pair of messages are used to create the downward routing table. The rank of a node represents its distance to the root node based on therouting metrics defined by the OF
Finally, the CC messages are the basis for the optional replayprotection mechanism, where non-repetitive nonce values areexchanged and used to assure no DIO message replay hadoccurred [1], [14].RPL standard offers a few security mechanisms to ensurecontrol messages’ confidentiality and integrity. Currently, RPLhas three modes of security [1], [13]: UM , where only the link-layer security is applied, if available (default mode); PSM ,which uses preinstalled symmetrical encryption keys to secureRPL control messages; and
ASM uses the preinstalled keys tolet the nodes join the network, after that all routing-capablenodes must acquire new keys from an authentication authority.As an optional security mechanism that is only available inthe preinstalled (PSMrp) or authenticated mode (ASMrp), RPLoffers a replay protection mechanism called the ConsistencyCheck. In these checks, special secure control messages (CCmessages) with non-repetitive nonce value are exchanged andused to assure no message replay had occurred [1], [14].It is worth mentioning that all of the popular Internet ofThings (IoT) operating systems (e.g., Contiki OS [12] andTinyOS [18]) have implemented RPL in UM only. To the bestof our knowledge, ASM has never been implemented, and itwas not until recently that PSM was implemented by Perazzo et al. [13], albeit in an experimental form.IV. T HE P ROPOSED C HAINED S ECURE M ODE (CSM)
A. Motivations
Our work in [8], [9] examined RPL secure modes’ perfor-mance under several routing attacks, and have shown that PSM(and by extension, ASM) can mitigate most of the externalattacks . At the same time, it does not enhance RPL’s securityagainst internal attacks . Furthermore, it showed that externaladversaries still can launch replay attacks, even when PSMrpis used (e.g., in the case of the WH attack.)A further investigation of RPL standard [1] shows that itonly provides confidentiality and integrity of its control mes-sages, without any verification of their sender’s authenticity.This opens the door wide open for attacks such as the Sybil,identity-cloning, eavesdropping, and replay attacks [2] to belaunched regardless of the secure mode RPL is running. Forexample, an external adversary can launch a Neighbor attack - see §V-B - by merely monitoring the "
Type " and "
Code "header fields in any ICMPv6 message to identify RPL’s DIOmessages , without the need to decrypt the actual message [8].The lack of sender authentication in RPL motivated us todevise an innovative method to overcome this problem, andNC came into the light as a possible solution. Incorporatingthe intra-flow NC into RPL provides any receiving node with aproof of message authenticity, assuming that the first messagecame from the original sender. This stands true for most An external attack refers to an attack that is launched by an adversarywho is not part of the network, e.g., it does not have the encryption keys usedby the legitimate nodes for RPL in PSM, or runs RPL in UM. An internal attack is launched by an adversary who is part of the network,e.g., it has the encryption keys used by the legitimate nodes for RPL in PSM. (Type = 155) means this is an RPL message. (Code = 1 or 129) means itis a regular or secure DIO message, respectively. EEE INTERNET OF THINGS, VOL. XX, NO. X, XXX 2021 3
RS DRS DRS D
P1 P1P2 P2 (a) Normal network communication
RS D
RS DRS D
P1 P2P1 Ꚛ P2 P1 Ꚛ P2 (P1 Ꚛ P2) Ꚛ P1 = P2 (P1 Ꚛ P2) Ꚛ P2 = P1 (b) Inter-flow NC
RS D
RS DRS D
P1 P1P1 Ꚛ P2 P1 Ꚛ P2 P2 Ꚛ P3 P2 Ꚛ P3 (c) Intra-flow NCFig. 1. Examples of NC communication. The ⊕ sign represents XOR as a simple NC operation.TABLE IL IST OF U SED A BBREVIATIONS FOR
CSM
Abbreviation Description
SC Secret ChainingxC Either Unicast ( UC ) or Multicast ( MC ) flowER Emergency flowTX TransmittingRX ReceivingSRRxx SC Recovery control message, either Request (SRReq)or Response (SRRes) attacks as the adversaries normally join the network after ithas been initiated and stabilized. B. Brief Review on Network Coding
NC has received a great deal of attention since it was firstproposed by Ahlswede et al. [19]. Many researchers haveinvestigated NC schemes (e.g.,
XOR , Random Linear NC , etc.)to improve network efficiency (e.g., throughput, reliability,and E2E delay) using different communication technologies(wired, wireless, or ad hoc networks) [20].The basic idea of NC is that a source combines multiplepieces of information or packets using a coding scheme andforwards the coded information to the next network device.The receiver then, upon receiving enough information, decodesthe combined information to recover the original data.The simplest NC scheme is XOR. For example, a device canperform bit-by-bit XOR operations of two packets in sequenceand forward the XOR-ed packet to the next hop to reduce thenumber of transmissions [19].NC can be applied to either inter-flow or intra-flow traffic.Inter-flow NC applies coding to packets from different trafficflows (see Fig.1b), whereas intra-flow NC uses coding forpackets of the same traffic flow [21], [22] (see Fig.1c), creatinga chain of messages. Inter-flow NC requires more complexoperations, such as buffering and synchronization of packetsfrom multiple flows or different sources. Intra-flow NC, on theother hand, is much easier as it only considers the sequenceof packets within the same flow, which makes it suitable tothe resource-constrained IoT.This paper proposes an innovative secure mode for RPL, theCSM, using the intra-flow NC. The chaining effect from thismethod adds sender authenticity to RPL (assuming that thefirst message came from the original sender) and increasesits resilience against several routing attacks (e.g. replay at-tacks). For concept demonstration only, we make use of thesimplest NC scheme, the XOR . However, more sophisticatedNC schemes can be used for higher level of security.
C. How CSM Operates
First, the used abbreviations are listed in Table I. The designof CSM is based on the following points: • Adhering to the RPL standard by maintaining the sameprocedures used for PSM. • Using intra-flow NC to provide broad replay-attacks-mitigation capability as part of RPL standard. • Allowing external security measures to integrate withCSM by controlling how RPL trusts nodes. • CSM’s primary focus is on protecting static networks, asthey constitute the majority of current IoT applications.However, mobility can be supported using the externalsecurity measure integration mentioned above.To implement the intra-flow NC, and instead of using theentire previous control message for the encoding / decoding of the current one (see Fig.1c), CSM uses the Secret Chain-ing (SC) values which are sent within the previous controlmessage. These SC values are 4-bytes unsigned, randomlygenerated integer numbers (for each sent control message),and are locally unique for each neighbor.Since RPL sends its control messages as either Multicast(MC) or Unicast (UC) messages, CSM considers them twoindependent flows: an MC-flow and a UC-flow. Hence, everynode in the network should maintain a table (the
SC table )of the following SC values for each neighbor, in order tosuccessfully encode and decode their control messages: • SC_UC_RX:
The SC value used to decode the nextincoming UC-flow message from the neighbor. • SC_MC_RX:
The SC value used to decode the nextincoming MC-flow message from the neighbor. • SC_UC_TX:
The SC value used to encode the nextoutgoing UC-flow message to the neighbor. • SC_ER_TX:
The SC value used to encode the nextoutgoing Emergency (ER)-flow message to the neighbor- see §IV-D.In addition, each node should maintain the next SC valuefor its next MC-flow transmission (
SC_MC_TX ) and ER-flow reception (
SC_ER_RX ) – see §IV-D. For simplicity, thecurrent CSM design uses zero as a value for the SC used forthe first transmission in each flow.To exchange the SC values used to encode the next controlmessage, CSM employs the
RPL Control Message Options from the standard [1]. These optional add-ons are used toprovide (or request) information to (or from) the receiver.CSM adds three new options to accommodate the transmissionof the next SC used for each flow: the (
SC_UC_NEXT ) EEE INTERNET OF THINGS, VOL. XX, NO. X, XXX 2021 4
Type Code Checksum
RPL Security Fields Base RPL Message SC-ER
Option
MAC/Digital
Signature
RPL
Option(s)
ICMPv6 Header ICMPv6 Payload = RPL Control Message
Encoded by CSM using the current SC-xC-TX value
Added by CSMCan be either SC-MC-NEXT only (MC-flow), or both SC-MC-NEXT and SC-UC-NEXT (UC-flow)
This part is ENCRYPTED using the preinstalled key, as per standard RPL in PSM procedures
The whole RPL message is ENCODED by CSM using the current SC-xC-TX value
SC-xC-NEXT
Option(s)
Fig. 2. Format of an RPL control message, as constructed by the proposed CSM. The black parts represents ICMPv6 header, the white parts are standardRPL in PSM fields, and the grey parts are added by CSM.
Start EndPrepare the RPL message as per RPL standard
Generate new
SC-xC value for the next message in the flow
Add the corresponding
SC_xC_NEXT
RPL option(s) with the generated SC valueEncrypt the message as per RPL PSM procedure
Encode the encrypted message with the current SC-xC-TX value
Encode the “ Code ” value corresponding to the message type with the same SC-xC-TX valueUpdate corresponding field in SC Table with the generated SC-xC Send the message in ICMPv6 container with the encoded “ Code ” value, as normal (a) Sending an RPL message StartRPL
Message ReceivedIs Sender inSC Table? Is “ Code ” field Encoded? Is “ Code ” field Encoded?
Does the decoded “ Code ” field match an RPL message type? Normal
RPL Procedures
Add sender to
Neighbor SC
Table
Drop MessageYes No
Yes No (Encoded with Zero)Yes No (Encoded with Zero)
Yes (Encoded with unknown
SC value)
NoDecode “ Code ” field with the stored SC value Decode the RPL message with the stored SC value SC Recovery
Procedures Is “ Code ” =
SRR msg? No Yes Is TrustVal >= TrustTrig ? Yes No (b) Receiving an RPL messageFig. 3. Flowcharts represent the sending and reception procedure of an RPLmessage in the current CSM prototype. option includes the SC value to be used for the next UC-flowmessage, ( SC_MC_NEXT ) is for the SC value to be used forthe next MC-flow message, and (
SC_ER ) is for the SC valueto be used for the next ER-flow message – see §IV-D.When a node wants to send an RPL control message(whether for the UC-, MC, or ER-flow), it will follow thefollowing steps (see Fig.3a):1) Prepare the message as per the standard PSM procedures.2) Generate a new SC value to be sent within the corre-sponding RPL option. This step is not performed for SC Recovery Request/Response (SRR) messages - see§IV-D.3) The
Code field of the ICMPv6 header is encoded usingthe corresponding SC_UC_TX or SC_MC_TX value tomitigate the security vulnerability addressed in §IV-A.The only exception is the
SRR messages, which keep theirdesignated ICMPv6 "Code" value without encoding – see§IV-D.4) Adding the (SC_xC_NEXT) and (SC_ER) new controlmessage options, as per the RPL standard. CSM shouldadd both the (SC_UC_NEXT) and (SC_MC_NEXT) forUC-flow messages and only the (SC_MC_NEXT) for theMC-flow messages. The use of both options for the UC-flow allows for quicker recovery from message chainbreakage in the MC-flow.After encrypting the message (according to standard PSMprocedures), CSM will encode the whole message using thecorresponding SC value then send it as usual. Fig.2 depictshow CSM constructs an RPL message, while Fig.3a representsa flowchart of RPL message sending procedure in CSM.At the receiving node, the decoding SC value is found fromthe SC table using the sender IP address. The found SC valueis used to decode the
Code field of the ICMPv6 header toidentify the type of RPL message, then the whole message isdecoded using the same SC value and is processed as per PSMprocedures. Any message with a non-decodable
Code field willbe discarded without processing. Fig.3b shows a flowchart formessage reception in CSM. Fig. 4 shows examples of CSMnormal operation.To allow integration with external security measures, CSMprovides a trust-based control interface for such securitysystems through the
TrustVal value. This value is part of theSC table and is allocated for each neighbor. It defines the trust-worthiness of that neighbor; hence, the acceptance or rejectionof its RPL control messages. The external security mechanism(such as an IDS) would set the boundaries for
TrustVal ; themaximum (
TrustValMax ) and minimum (
TrustValMin ), and thetrigger value (
TrustTrig ) that, if
TrustVal went below it, CSMwill drop any RPL control messages from that neighbor. Inaddition, the calculation of
TrustVal is left to the externalmechanism and can be dynamic to allow for larger flexibilityto different applications and scenarios. For example, an IDScan use its own methods (e.g., special messages, monitoringthe traffic, etc.) to determine the neighbor’s trustworthiness;then it updates
TrustVal in the SC table, which tells CSM if itshould accept or reject control messages from that neighbor.
EEE INTERNET OF THINGS, VOL. XX, NO. X, XXX 2021 5
Node ANode A Node BNode B (Multicast Message, SC_MC_NEXT = A020,
SC_ER = CDEF) (Multicast Message, SC_MC_NEXT = 035D,
SC_ER = B024) (Unicast Message, SC_UC_NEXT = DBA0, SC_MC_NEXT = A020, SC_ER = CDEF) (Multicast Message, SC_MC_NEXT = 1825,
SC_ER = B024) (Unicast Message, SC_UC_NEXT = 8B5E,
SC_MC_NEXT = A020, SC_ER = CDEF) (Unicast Message, SC_UC_NEXT = EC4F,
SC_MC_NEXT = 035D, SC_ER = B024) (a)(b)(c) (d) (e) (f)
Neighbor
A020
SC-MC-TX
A020
SC-ER-RX
CDEF
SC-ER-RX
CDEF
Neighbor
A020
SC-ER-RX
CDEF
Neighbor
Neighbor
Neighbor B SC-MC-RX SC-UC-RX SC-UC-TX
SC-ER-TX
B024
Neighbor B SC-MC-RX SC-UC-RX SC-UC-TX
SC-ER-TX
B024
SC-MC-TX
A020
SC-MC-TX
A020
SC-ER-RX
CDEF
SC-ER-RX
CDEF
Neighbor B SC-MC-RX SC-UC-RX SC-UC-TX
SC-ER-TX
B024
SC-MC-TX
A020
SC-ER-RX
CDEF Neighbor A SC-MC-RX SC-UC-RX SC-UC-TX
A020 EC4F
SC-ER-TX
CDEF
Neighbor A SC-MC-RX SC-UC-RX SC-UC-TX
A020 EC4F
SC-ER-TX
CDEF
SC-MC-TX
SC-MC-TX
SC-ER-RX
B024
SC-ER-RX
B024
Neighbor A SC-MC-RX SC-UC-RX SC-UC-TX
A020 EC4F
SC-ER-TX
CDEF
SC-MC-TX
SC-ER-RX
B024
Neighbor B SC-MC-RX SC-UC-RX SC-UC-TX
SC-ER-TX
B024
Neighbor B SC-MC-RX SC-UC-RX SC-UC-TX
SC-ER-TX
B024
SC-MC-TX
A020
SC-MC-TX
A020
SC-ER-RX
CDEF
SC-ER-RX
CDEF
Neighbor B SC-MC-RX SC-UC-RX SC-UC-TX
SC-ER-TX
B024
SC-MC-TX
A020
SC-ER-RX
CDEFNeighbor
Neighbor
Neighbor B SC-MC-RX SC-UC-RX SC-UC-TX
SC-ER-TX
B024
Neighbor B SC-MC-RX SC-UC-RX SC-UC-TX
SC-ER-TX
B024
SC-MC-TX
A020
SC-MC-TX
A020
SC-ER-RX
CDEF
SC-ER-RX
CDEF
Neighbor B SC-MC-RX SC-UC-RX SC-UC-TX
SC-ER-TX
B024
SC-MC-TX
A020
SC-ER-RX
CDEF
Fig. 4. Examples of normal CSM operation in chronological order (the number on the top-right of the brackets represents the SC value used to encode thatmessage): (a and b) the first message in the MC-flow, (c and d) the first message in the UC-flow, (e) subsequent messages of the UC-flow, and (f) subsequentmessages of the MC-flow. The yellow color highlights a creation or a change of an SC value in the SC table.
D. SC Recovery Mechanism
Our initial work [11] showed that CSM requires a proper re-covery mechanism when a control message from any NC flowis missed or lost, otherwise all subsequent communications inthat flow will be discarded due to not having the correct SCvalue to decode it.As CSM is designed for the static networks, there are twocases where nodes can loose track of the SC values:-1)
Node Reset:
When a node is reset for any reason (e.g.,battery replacement, firmware upgrades, etc.), it will loseall stored SC values and start from scratch. For this, CSMassumes that the OS will periodically save all SC values(node’s own and SC table) to the filesystem, and loadsthem at boot-up time, so the node can resume from thepoint just before the reset.2)
Lost or Corrupt Messages:
Missing a control messageis normal for lossy networks such as the ones RPL isdesigned for [1]. However, in CSM this means breakingthe message-chain for one of (or both) flows, resulting indiscarding all subsequent messages of the broken flow.To recover from the second case mentioned above, CSMimplements a special recovery mechanism, dubbed the
SCRecovery . This recovery mechanism applies only to the neigh-bors that are already in the SC table. To secure the recoveryprocess, the SC values are not sent as clear text. Instead,a challenge/response exchange is performed based on theconcept of solving Linear Algebra equations that involves themissing SC values. In general, assuming that node (A) is thereceiver of the "non-decodable" message and node (B) is theoriginal sender, node (A) will send an SC Recovery Request(SRReq) message to node (B) containing the coefficients ofa system of linear equations, to which node (B) will use thecoefficients and its next SC values to calculate the results of thelinear equations. These results are replied to node (A) inside an SC Recovery Response (SRRes) message. Now, node (A)will use the provided information to solve the linear equationsand extracts the missing SC values for node (B). The reasonbehind this procedure is to raise the bar for the adversaries tolaunch attacks against (or abusing) the recovery mechanism.Based on the above-mentioned concept, The SC recoverymechanism goes as follows: • A new NC flow is added to CSM, the
Emergency (ER)flow , to be used when exchanging the SRR messages.Each node will maintain an SC value (
SC_ER ) for thisflow, and exchanges it through the (
SC_ER ) option inevery message of the other flows – see §IV-C. However,the SC_ER only updates after a successful recovery. • When a message is received, if the decoded "Code" fieldat the ICMPv6 header of the received message does notrepresent an RPL control message, the following methodsare performed to recover the missing SC value: – If the received message was from the MC-flow, aregular UC-DIS message is sent to the sender. As perRPL standard, the sender must reply with a regularUC-DIO, which will have all the correct SC values forthe next message in all the flows. – If the received message was from the UC-flow, the SCrecovery mechanism is conducted:1) The received message will be discarded.2) The receiver sends a UC-SRReq message to theoriginal sender, containing the randomly-generatedcoefficient values to be used by the original senderas explained above. The SRReq is encoded withthe original sender’s
SC_ER value.3) Once receiving the SRReq message, the origi-nal sender will calculate the results of the linearequations, then it sends them within a MC-SRResmessage to the receiver, encoded with the receiver’s
EEE INTERNET OF THINGS, VOL. XX, NO. X, XXX 2021 6
SC_ER value. Since this is a multicast message,the SRRes message contains the Internet Proto-col version 6 (IPv6) address of the node that issupposed to process it. In addition, the originalsender will update his SC_ER and send it withinthe corresponding RPL option.4) Now, the receiver will use the coefficients and thereceived results to solve the linear equations andupdate its SC table with the extracted SC values.V. E
VALUATION OF THE C HAINED S ECURE M ODE
To evaluate our proposed CSM, we conducted a comparisonon security and performance between our devised prototypeof CSM and the currently implemented secure modes: RPL inUM (vanilla ContikiRPL), PSM, and PSMrp (both accordingto Perazzo et al. [13] implementation). All secure modes weretested against three routing attacks (NA, CA, and WH).
A. Evaluation Setup and Assumptions
Cooja, the simulator for Contiki OS [12], was used for allthe simulations (with simulated motes). Fig.5 shows the topol-ogy used in our evaluation. A list of simulation parameters isprovided in Table II.For the purpose of the evaluation, these metrics were used:the average data PDR, average data E2E latency, and theaverage network power consumption per received data packet.The following assumptions were used in our evaluation: allthe legitimate nodes send data packets toward the root at a rateof 1 packet/minute per node, while the adversary does not sendany data packets. For all the evaluated secure modes, RPL isset up with the default OF, namely the Minimum Rank withHysteresis Objective Function (MRHOF) [23]. Contiki OS isusing the following settings for its uIP stack: IEEE 802.15.4[24] for the Physical layer and Medium Access Control (MAC)sublayer, ContikiMAC [25] and NullRDC [12] for the RadioDuty-Cycle (RDC) sublayer (see below), IPv6 and RPL atthe Network layer, and UDP for the Transport layer. To keepthe focus on RPL, we assumed neither security measures norencryption were enabled at the Link layer.As explained in our previous work [8], Contiki OS supportsseveral RDC protocols [12], with the ContikiMAC and Null-RDC being the most common ones. The main difference be-tween the two is that ContikiMAC is designed to aggressivelyconserve energy more than NullRDC, at the expense of havinglonger E2E latency [8], [26]. In this paper, the implementationof the WH attack is based on our work in [8]; hence, it is onlyavailable using NullRDC protocol.The data traffic model used for the evaluation, as describedabove, is a deterministic one that mimics a typical sensing-IoTnetwork, where nodes send their sensor readings toward theroot node at predetermined periods.To test the external mechanism integration capability ofCSM, the following simple, proof-of-concept, external securitymechanism was implemented (only in CSM experiment): • TrustValMin , TrustValMax , and
TrustTrig were set to 0,100, and 50, respectively. • For the first RPL message from a neighbor, a successfulreception will set
TrustVal to TrustValMax .
12 28 34 56 789 1011 1213 14 15
17 18 19 20 2122 2324 25 26 2728 29
Fig. 5. Network topology used for the evaluation. The adversaries’ locationsare represented by a dark-purple circle (No Attack, NA, and CA scenarios)or the light-purple ones (WH scenario.)TABLE IIL
IST OF S IMULATION P ARAMETERS ( PER
RDC
PROTOCOL ) Description Value
No. of simulation sets Two: one for each adversary type( I nternal and E xternal) (See §V-B)No. of experiments per set Four: one for each secure mode (UM,PSM, PSMrp, and CSM)No. of scenarios per experiment 3 (ContikiMAC) / 4 (NullRDC) - See§V-ASim. rounds per scenario / time 10 rounds / 20 min. per roundNode positioning Random distributionDeployment area 210m W x 150m LNumber of nodes 28 (29 for the WH scenario)includes 1 adversary (2 for WH)Sensor nodes type Arago Sys. Wismote mote • Afterward, TrustVal will increase or decrease based onthe successful (or unsuccessful) decoding of the receivedRPL control messages. The increment/decrement amountwas set to 10.The results obtained from the simulations were averagedover ten rounds per experiment with a 95% confidence level.
B. Adversary Model and Attack Scenarios
The following attacks were chosen due to the low costfor the adversary to launch them, as they require little or noprocessing of RPL’s messages. At the same time, the effect ofthese attacks can be significant on the network.All the secure modes were evaluated in both normal oper-ation (
No Attack ) and against three replay routing attacks [2],[27] (the following depicts our implementation of the attacks):-1)
Neighbor attack (NA):
Whenever the adversary hearsa DIO message from any neighbor (regardless of itsdestination), it will replay it (as a multicast) to all itsneighbors without modifications or processing, illudingthem to think that the original sender is within their range.If the original sender has a better rank (see §III), the
EEE INTERNET OF THINGS, VOL. XX, NO. X, XXX 2021 7
Average Packet Delivery Rate (PDR)
UM-I PSM-I PSMrp-I CSM-I (a) S e c o nd s Average Network E2E Latency
UM-I PSM-I PSMrp-I CSM-I (b) No Attack Neighbor Attack CloneID Attack m W a tt s Average Network Power Consumption(Per Received Packet)
UM-I PSM-I PSMrp-I CSM-I (c)Fig. 6. Simulation results for the four experiments (three attacks scenarios - internal adversary), using ContikiMAC RDC protocol.
Average Packet Delivery Rate (PDR)
UM-I PSM-I PSMrp-I CSM-I (a)
250 No Attack Neighbor Attack CloneID Attack Wormhole Attack S e c o nd s Average Network E2E Latency
UM-I PSM-I PSMrp-I CSM-I (b) No Attack Neighbor Attack CloneID Attack Wormhole Attack m W a tt s Average Network Power Consumption(Per Received Packet)
UM-I PSM-I PSMrp-I CSM-I (c)Fig. 7. Simulation results for the four experiments (four attacks scenarios - internal adversary), using NullRDC RDC protocol. receivers of the replayed message will select it as theirpreferred parent, which may result in lost data packetsand longer E2E delays [8].2)
CloneID attack (CA):
The adversary will clone the iden-tity of another node, in our case node (25), by changingits IPv6 and MAC addresses to match that of the clonednode (by monitoring its frames and RPL messages). Inaddition, it will follow and copy the cloned node’s rank byreading its DIO messages. Our implementation combinedCA with a Selective-Forward (SF) attack (that only dropsdata packets passing through the adversary) to better showhow the CA changed the DODAG around the adversary.3)
Out-of-Band Wormhole (WH) attack:
Two adversaries(connected by an out-of-band link) will forward andreplay all RPL control messages they hear from theirneighbors between the two locations where they reside.Due to simulation limitations [8], this attack scenario isonly available in the NullRDC set of experiments.For the adversaries, they run in the same RPL secure modeas the legitimate nodes. However, they have two types:
Internal adversaries, where they have the proper preinstalled encryptionkey for PSM, PSMrp, and CSM experiments (but not the SCvalues); and the
External adversaries, which do not have therequired encryption keys. Also, it is worth mentioning thatthe external and internal versions of the adversaries in UMscenario are the same.In all cases, the adversary starts as a legitimate node, tries to join the network, then launches the attack after two minutes.For the Wormhole attack, the two adversaries are always inpromiscuous mode and never participate in the DODAG.VI. R
ESULTS FOR I NTERNAL A DVERSARY S ETS
A. Effects on the Data PDR
Looking at Fig.6a (ContikiMAC) and Fig.7a (NullRDC),it is clear that PSMrp and CSM (for both ContikiMAC andNullRDC) successfully eliminated the NA effect, with both ofthem having almost 100% PDR. UM and PSM suffered more(PDR ≈ ≈ ≈ untrusted " both the legitimate andcloned nodes after several unsuccessful recovery attempts.Finally, CSM outperformed the other secure modes in theWH attack scenario, where it was able to mitigate the attack(PDR ≈ EEE INTERNET OF THINGS, VOL. XX, NO. X, XXX 2021 8
Average Packet Delivery Rate (PDR)
UM-I PSM-E PSMrp-E CSM-E (a) S e c o nd s Average Network E2E Latency
UM-I PSM-E PSMrp-E CSM-E (b) m W a tt s Average Network Power Consumption(Per Received Packet)
UM-I PSM-E PSMrp-E CSM-E (c)Fig. 8. Simulation results for the four experiments (three attacks scenarios - external adversary), using ContikiMAC RDC protocol.
Average Packet Delivery Rate (PDR)
UM-I PSM-E PSMrp-E CSM-E (a) S e c o nd s Average Network E2E Latency
UM-I PSM-E PSMrp-E CSM-E (b) No Attack Neighbor Attack CloneID Attack Wormhole Attack m W a tt s Average Network Power Consumption (Per Received Packet)
UM-I PSM-E PSMrp-E CSM-E (c)Fig. 9. Simulation results for the four experiments (four attacks scenarios - external adversary), using NulRDC RDC protocol. if they were encoded with unknown SC values. Hence, therouting topology will not change due to the WH attack.
B. Effects on the Data E2E Latency
Looking at Fig.6b (ContikiMAC) and Fig.7b (NullRDC), itcan be seen that NA has been mitigated by both PSMrp andCSM (latency ≈ a few milliseconds), and that it introducedhigher E2E latency to the network for the other secure modes( ≈ sleep times [8], [26].Further proofing CSM’s ability to mitigate the WH attack,latency is kept to minimum (<5 seconds) compared to the othersecure modes ( ≈ C. Effects on Power Consumption
Comparing Fig.6c (ContikiMAC) and 7c (NullRDC), it canbe seen that all secure modes have similar patterns, where theCA scenario has the higher power consumption in the Contiki-MAC set, and the WH attack scenario has the highest powerconsumption in the NullRDC set. However, CSM has the lowest power consumption in every situation when comparedto other secure modes. This is more prominent in the WHattack scenario. It is worth mentioning that power readingsfor NullRDC are higher than the ones for ContikiMAC, as thetransceiver is always on for the former while it is off most ofthe time for the latter [8], [9].VII. R
ESULTS FOR E XTERNAL A DVERSARY S ETS
A. Effects on the Data PDR
Fig.8a (ContikiMAC) and Fig.9a (NullRDC) show thatPSM, PSMrp, and CSM are capable of mitigating both NAand CA, with the latter having a slightly more effect in thecase of ContikiMAC set (PDR ≈ ≈ ≈ fresh "or not; hence, if it should keep it in its possible-parents list or EEE INTERNET OF THINGS, VOL. XX, NO. X, XXX 2021 9 even as the preferred parent [1]. However, NullRDC does notprovide such statistics, leaving RPL only to use its statistics.Since the dropped RPL control messages are still success-fully received by ContikiMAC, it will affect RPL’s decisionon keeping the victim node (and the cloned node - adversary)as the preferred parent at the neighboring nodes. In manycases, it will prolong the time required to switch to anotherparent until RPL’s statistics point to a communication failureand force the switch, unlike the case for NullRDC whereRPL quickly detects the communication failure and switch toanother parent.
B. Effects on the Data E2E Latency similar to the analysis of PDR, Fig.8b (ContikiMAC) andFig.9b (NullRDC) show that the three secure modes havesuccessfully mitigated the NA, while the CA still has an effectin the case of ContikiMAC for the same reason mentionedabove. Again, CSM shows as the only secure mode capableof mitigating the WH attack, with minimum E2E latency.
C. Effects on Power Consumption
The results for ContikiMAC (Fig.8c) shows similar patternsamong all the secure modes and for all attacks as a proof ofsignificant attacks’ mitigation. However, PSM, PSMrp, andCSM do have a slightly more power consumption than UMin the No Attack scenario, due to the additional securitymeasures. This case is reversed for the CA attack scenario,as the UM was the only mode fully affected by the attack.Fig.9c show that all three secure modes have similar patternsfor the NA and CA scenarios (significant mitigation of theattacks) under NullRDC. While, for the WH attack, CSMhas the lowest power consumption (matching the No Attackscenario), due to the mitigation of the attack.VIII. D
ISCUSSION
Our observations from the evaluation experiments can besummarized in the following points:
A. Enhanced Security Features of CSM
Those can be summarized as follows:i) CSM adds an extra layer of security by encoding thecontrol messages and chaining them with the SC values,providing a mean of sender authentication which lim-its the adversaries’ ability to eavesdrop on, manipulate,forge, and replay RPL control messages.ii) Due to the encoding of the
Code field of the ICMPv6header in CSM, external adversaries cannot identify thetype of RPL control messages by reading the ICMPv6header, except for the first message of each message flowas it is currently encoded with zero - see Fig.4c. Hence,external replay attacks that target specific RPL controlmessages (e.g., NA) can be mitigated by using CSM.iii) Unlike PSMrp, CSM provides mitigation to both "one-way" and "two-way replay attacks (e.g., the NA and WH,respectively), due to the chaining of the control messages(by the SC values) that acts as a sender authenticationmechanism, without the need for a challenge/responsemechanism as in PSMrp.
B. CSM Reduction of the In-threat Period
The in-threat period can be defined as " the time duration inwhich an adversary can overhear and understand the whole(or a part of) the exchanged RPL control messages and launchattacks ". This period ranges between zero ( the adversarycannot launch attacks successfully ) to infinity ( the adversarycan launch attacks at any time ), depending on the secure modeused, the adversary type, and the attack.For UM, the in-threat period is always infinity as theadversary can understand RPL messages and launch attacksat any time. On the other hand, the in-threat period for PSMcan be either: • Infinity for all internal adversaries, or external adver-saries of replay/identity-cloning attacks. The former candecrypt the whole control message with the preinstalledencryption key at any time, while the latter can identifyRPL control messages from the "Type" and "Code" fieldsof the ICMPv6 header, then replay them at any other timewithout the need to decrypt the message contents. • Zero for external adversaries of attacks that require a fullunderstanding of RPL control messages, due to the lackof the used encryption key.As CSM enhances RPL security through the intra-flow NC,it limits the adversaries’ ability to launch several internaland external attacks that require identifying and understandingRPL control messages. Hence, CSM significantly reduces thein-threat period to either: • The time between receiving the first MC and the firstUC messages for all internal adversaries. During thisperiod, the adversary will try to intercept the first UCcontrol message (which is encoded with zeros and hasthe SC values for both UC and MC flows), so it canuse the included SC values to decode (then decrypt) thefollowing message from any flow. However, the adversaryneeds to continuously intercept and decode all messagesfrom its victims in order to keep up with used SC values,which significantly raises the cost of any attack’s launch. • Zero for all external adversaries, due to the lack of boththe used encryption key and the correct SC values. Inaddition, CSM’s encoding of the "Code" field of theICMPv6 header makes it harder to the adversary toidentify the type of RPL control message; hence, moredifficult to launch message-specific replay attacks.To further reduce the in-threat period for CSM, we proposethat RPL should be forced to send the first UC message assoon as it finishes processing the first MC message.IX. C
ONCLUSION
In this paper, we proposed a novel secure mode for RPL, theChained Secure Mode, that is based on the concept of intra-flow NC, to enhance RPL security and to build a mitigationcapability of replay attacks into the protocol itself, withoutsignificantly changing the way RPL works. A prototype ofCSM was devised, and its security and performance wereevaluated against the currently implemented secure modesof RPL (UM, PSM, and PSMrp) under three replay routingattacks (NA, CA, and WH attack). It was shown that CSM
EEE INTERNET OF THINGS, VOL. XX, NO. X, XXX 2021 10 successfully mitigated the replay attacks (NA and WH attack)while significantly reduced the effect of CA, all with latencyand power consumption less than the other secure modes.Also, it was shown that CSM has a significantly smaller in-threat period than all other secure modes. In addition, theability to integrate external security mechanism opens the doorto further enhance RPL security through future expansions. Forexample, it is possible to support mobility vie suitable externalsecurity mechanism that would allow CSM to trust the mobilenodes, which is left for future work.A
CKNOWLEDGMENT
The authors acknowledge support from the Natural Sci-ences and Engineering Research Council of Canada (NSERC)through the Discovery Grant program.R
EFERENCES[1] T. Winter et al. , “RPL: IPv6 Routing Protocol for Low Power and LossyNetworks,” RFC Editor, RFC 6550, March 2012.[2] A. Raoof, A. Matrawy, and C.-H. Lung, “Routing Attacks and MitigationMethods for RPL-Based Internet of Things,”
IEEE Comm. Surveys andTutorials , vol. 21, no. 2, pp. 1582–1606, 2nd Quarter 2019.[3] P. Perazzo et al. , “Implementation of a Wormhole Attack against a RPLNetwork: Challenges and Effects,” in . IEEE, Feb 2018, pp. 95–102.[4] A. Aris et al. , “RPL Version Number Attacks: In-depth Study,” in
IEEE/IFIP Netw. Oper. and Manage. Symp. (NOMS-2016) , 2016.[5] A. Dvir, T. Holczer, and L. Buttyan, “VeRA - Version Number andRank Authentication in RPL,” in , 2011, pp. 709–714.[6] F. Gara et al. , “An intrusion detection system for selective forwardingattack in IPv6-based mobile WSNs,” , 2017.[7] H. Perrey et al. , “TRAIL : Topology Authentication in RPL,” in
Int’lConf. on Embedded Wireless Sys. and Networks , 2016.[8] A. Raoof, A. Matrawy, and C.-H. Lung, “Enhancing Routing Securityin IoT: Performance Evaluation of RPL Secure Mode under Attacks,”
IEEE Internet of Things Journal , vol. 7, no. 12, pp. 11 536 – 11 546,Dec 2020.[9] ——, “Secure Routing in IoT: Evaluation of RPL’s Secure Mode underAttacks,” in
IEEE Global Commun. Conf. (GLOBECOM 2019) , 2019.[10] A. Arena et al. , “Evaluating and Improving the Scalability of RPLSecurity in the Internet of Things,”
Computer Commun. , vol. 151, 2020.[11] A. Raoof, C.-H. Lung, and A. Matrawy, “Introducing Network Codingto RPL: The Chained Secure Mode (CSM),” in
The 19th IEEE Int. Symp.on Netw. Comput. and App. (NCA) . IEEE, 2020.[12] A. Dunkels et al. , “Contiki - a Lightweight and Flexible OperatingSystem for Tiny Networked Sensors,” in , Nov 2004.[13] P. Perazzo et al. , “An Implementation and Evaluation of the SecurityFeatures of RPL,” in ,vol. 10517. Springer Int’l Pub., 2017, pp. 63–76.[14] D. Airehrour et al. , “SecTrust-RPL: A secure trust-aware RPL routingprotocol for IoT,”
Fut. Gen. Comp. Sys. , vol. 93, Apr 2019.[15] ——, “SecTrust: A Trust and Recommendation System for Peer-2-PeerNetworks,” in
Int. Conf. on Inf. Resour. Manage. (CONF-IRM) , 2018.[16] N. Janicijevic et al. , “Routing Protocol for Low-power and LossyWireless Sensor Networks,” in , 2011.[17] J. Granjal et al. , “Security for the Internet of Things: A Survey ofExisting Protocols and Open Research Issues,”
IEEE Comm. Surveysand Tutorials , vol. 17, no. 3, pp. 1294–1312, 2015.[18] P. Levis et al. , “Tinyos: An operating system for sensor networks,” in
Ambient Intelligence . Berlin, Germany: Springer, 2005, pp. 115–148.[19] R. Ahlswede et al. , “Network information flow,”
IEEE Trans. on Info.Theory , vol. 46, no. 4, pp. 1204–1216, 2000.[20] M. Hay et al. , “Network Coding and Quality of Service for Mobile AdHoc Networks,”
Int. Journal of Commun., Network and System Sciences ,vol. 07, no. 10, pp. 409–422, 2014.[21] J. Hansen et al. , “Bridging Inter-Flow and Intra-Flow Network Coding inWireless Mesh Networks: From Theory to Implementation,”
ComputerNetworks , vol. 145, pp. 1–12, 2018. [22] B. Saeed et al. , “Multimedia Streaming for Ad Hoc Wireless MeshNetworks Using Network Coding,”
Int. Journal of Commun., Networkand System Sciences , vol. 06, no. 05, pp. 204–220, 2013.[23] O. Gnawali and P. Levis, “The Minimum Rank with Hysteresis ObjectiveFunction,” RFC 6719, September 2012.[24]
IEEE Standard for Low-Rate Wireless Networks , IEEE Std. 802.15.4-2015, April 2015.[25] A. Dunkels, “The ContikiMAC Radio Duty Cycling Protocol,” SwedishInstitute of Computer Science, Technical Report, Dec 2011.[26] A. Y. Barnawi et al. , “Performance Analysis of RPL Protocol forData Gathering Applications in Wireless Sensor Networks,”
ProcediaComputer Science , vol. 151, no. 2018, pp. 185–193, 2019.[27] L. Wallgren et al. , “Routing Attacks and Countermeasures in the RPL-based Internet of Things,”
Int’l Journal of Dist. Sensor Net. , vol. 2013.[28] C. Bormann et al. , “Neighbor Discovery Optimization for IPv6 overLow-Power Wireless Personal Area Networks (6LoWPANs),” RFC6775, Nov 2012.[29] M. P. Uwase et al. , “Experimental Comparison of Radio Duty CyclingProtocols for Wireless Sensor Networks,”
IEEE Sensors Journal , vol. 17,no. 19, pp. 6474–6482, 2017.
Ahmed Raoof is a graduate from University ofBenghazi, Libya; where he received his B.Sc. degreein Electrical and Electronic Eng. (2003), and M.Sc.in Telecomm. Eng. (2009). After that, he worked inthe same university as a lecturer at the Departmentof Comp. Net., Faculty of Information Technology(2009 - 2013). Currently, he is pursuing the Ph.D.degree with the Department of Sys. and Comp.Eng. at Carleton University. His research focuseson network protocols and the security of computernetworks and Internet of Things.
Chung-Horng Lung (Senior Member, IEEE) re-ceived the B.S. degree (1982) in Comp. Scienceand Eng. from Chung-Yuan Christian University,Taoyuan, Taiwan, and the M.S. (1988) and Ph.D.(1994) degrees in Computer Science and Eng. fromArizona State University ,Tempe, AZ, USA. Hewas with Nortel Networks, Ottawa, ON, Canadafrom 1995 to 2001. In September 2001, he joinedthe Department of Systems and Computer Eng.,Carleton University, Ottawa, where he is currentlya Professor. His research interests include: Commu-nication Networks, Software Engineering, and Cloud Computing.