Int. J. Security and Networks, Vol. x, No. x, xxxx 1

Group-IKEv2 for multicast IPsec in the internet ofthings

Kiki Rizki, Argyro Lamproudi, Marco Tiloca andShahid Raza*SICS Security Lab,RISE Research Institutes of Sweden,Isafjordsgatan 22, 16440 Kista,Stockholm, SwedenEmail: kk.rizki@gmail.comEmail: arglam90@gmail.comEmail: marco.tiloca@ri.seEmail: shahid.raza@ri.se*Corresponding author

Abstract: This paper presents Group-IKEv2, a group key management protocol supportingsecure group communication based on multicast IPsec. Group-IKEv2 is an adaptation ofthe IKEv2 protocol for the IPsec suite, and is especially designed to address internetof things (IoT) scenarios composed of resource-constrained devices. Compared to staticapproaches, Group-IKEv2 enables dynamic and flexible establishment of IPsec group securityassociations as well as group key material. Also, it integrates the management andrenewal of group key material, both on a periodical fashion and upon group membershipchanges. We have implemented Group-IKEv2 for the Contiki OS and tested it on theOpenMote resource-constrained platform. Our experimental performance evaluation confirmsthat Group-IKEv2 is affordable and deployable also on constrained IoT devices.

Keywords: security; Group-IKEv2; multicast IPsec; group communication; securecommunication; key management; internet of things.

Reference to this paper should be made as follows: Rizki, K., Lamproudi, A., Tiloca, M. andRaza, S. (xxxx) ‘Group-IKEv2 for multicast IPsec in the internet of things’, Int. J. Security andNetworks, Vol. x, No. x, pp.xxx–xxx.

Biographical notes: Kiki Rizki worked as a researcher at the SICS Security Lab of RISEResearch Institutes of Sweden, Stockholm, Sweden, where she carried out her MSc thesis work.She received her Master’s in Research on Information and Communication Technologies fromthe KTH Royal Institute of Technology, Stockholm, Sweden in 2016. Her research interestsinclude security in the IoT and key management.

Argyro Lamproudi carried out her MSc thesis work at the SICS Security Lab of RISEResearch Institutes of Sweden, Stockholm, Sweden. She graduated at the Chalmers Universityof Technology, Gothenburg, Sweden in 2016, under the Master’s Thesis Program inCommunication Engineering.

Marco Tiloca is a senior researcher at the SICS Security Lab of RISE Research Institutes ofSweden, Stockholm, Sweden. He received his Bachelor’s and Master’s with Cum Laude inComputer Engineering from the University of Pisa, Italy, in 2006 and 2009, respectively. Hereceived his PhD in Computer Engineering from the University of Pisa in 2013, with focuson network and communication security in wireless sensor networks. His research interests arein the field of network security and include security in the internet of things, secure groupcommunication, key management, denial of service attacks and simulative evaluation of networkattacks. He has been involved in European research projects also as a Work Package Leaderand an active contributor of standardisation activities under the Internet Engineering Task Force(IETF).

Shahid Raza is a Lab Manager and an expert researcher at the SICS Security Lab of RISEResearch Institutes of Sweden, Stockholm, Sweden, where he has been working since 2008.He is also an Associate Professor (Docent) at the Uppsala University Sweden. He receivedhis Master from the KTH Royal Institute of Technology, Stockholm, Sweden, and completedhis Industrial PhD from the RISE SICS. His research interests include security and privacyin IPv6-connected internet of things, interconnection of computing clouds and IoT, blockchain,

Copyright 20XX Inderscience Enterprises Ltd.

2 K. Rizki et al.

and cloud security. He participated in a number of EU and Swedish projects and received astrategic grant from the Vinnova SIP-IoT program, a three years grant from the EU Eurostars, astrategic four years grant from the VR Sweden, and an extremely competitive five years grantfrom the SSF Sweden for an Institute PhD student.

1 Introduction

The internet of things (IoT) is now a consolidated paradigmwhere a large number of devices from everyday life are ableto communicate over IP and are available on the internet.This especially includes several heterogeneous classes ofdevices, which are often constrained in terms of resourcesas memory, computing power and energy availability.Typical IoT applications span a wide range of use cases,from battery-powered sensor networks to management ofsmart home appliances, or even control of industrial criticalinfrastructures.

A number of IoT application scenarios greatly benefitfrom group communication. This is commonly achievedby means of IP multicast paired with supporting routingprotocols, and enables a transmitter device to send asingle message addressed to multiple recipients registeredas members of a same group. The major advantageis an improvement in network performance as well asa considerably reduced energy consumption, which isespecially relevant in the case of battery-powered devices.Typical IoT applications based on group communicationare smart lighting control, emergency broadcast, massivereconfiguration of common parameters, and group softwareupgrade.

In order to enable the full potential of suchIoT applications, it is vital to ensure security ofdeployed networked scenarios. This greatly leveragessecure communication, in order to counteract cyber attacksagainst message exchange, and thus effectively preventsevere implications in data breach, privacy violations oreven safety. Typically, secure communication includes theassurance of requirements such as message confidentialityand integrity, source authentication and anti-replay, whichcan be achieved through different security protocols atdifferent layers of the internet stack.

In particular, the internet protocol security (IPsec)standard suite (Seo and Kent, 2005) provides securecommunication at the network layer, so counteractinga broader range of security attacks including, e.g., IPspoofing. Also, it natively integrates the enforcement oftraffic and security policies for filtering IP packets. As analternative to less flexible link layer protocols, IPsec is oneof the few standard solutions providing also secure groupcommunication (Gross et al., 2008), on top of IP multicast.

Furthermore, IPsec practically relies on securityassociations (SAs) established among peers, which includeconfiguration parameters and cryptographic material toactually enable and maintain secure channels. In particular,SAs can be handled manually, or more conveniently

established and managed by using the standard keymanagement protocol internet key exchange version 2(IKEv2) (Kaufman et al., 2014). However, when IPsec isused in a group communication context, the related groupsecurity association (GSA) is typically and inconvenientlyhandled in a manual fashion. That is, there is currentlyno standard adaptation of IKEv2 to establish, revoke andrenew IPsec GSAs.

This paper presents Group-IKEv2, a group keymanagement protocol that adapts and extends IKEv2 tosupport secure group communication based on IPsec.Group-IKEv2 relies on a centralised group controller/keyserver (GC/KS), in order to assist the authenticatedand secure enrolment of new group members, as wellas the establishment and management of IPsec GSAs.Furthermore, it handles the revocation and renewal of groupkey material, namely rekeying.

Our protocol Group-IKEv2 builds on and improves aprevious proposal discussed in the internet draft (Weisand Smyslov, 2018), and specifically distinguishes itselffor the following benefits. First, it is especially designedto be affordable and deployable in IoT networkedscenarios, where both the group members and the GC/KSare resource-constrained devices. Second, it integrates afull-fledge group key management scheme for rekeyingthe group, both in a periodical fashion and upon groupmembership changes, i.e., when a new node joins the groupor a current member leaves the group.

We implemented Group-IKEv2 for the Contiki OS(Contiki, 2017) and tested it on real IoT devices fromthe OpenMote resource-constrained platform (OpenMote,2017). Our implementation is available as open sourcesoftware at Rizki (2017). To the best of our knowledge,this is the first implementation providing a group-adaptationof IKEv2 for the Contiki OS, and the first one targetingIoT scenarios where also the GC/KS is deployed as aresource-constrained device.

We have used our implementation to perform anexperimental performance evaluation of Group-IKEv2,upon the dynamic joining of new group members andvia different authentication methods. In particular, wetook into account memory consumption, message size,energy consumption, and time required to fully set upor solely rekey an IPsec multicast group. Our resultsshow that, under different configurations, Group-IKEv2is affordable in resource-constrained devices and thuseffectively deployable to enable IPsec group communicationin IoT networked scenarios.

The rest of the paper is organised as follows. Section 2discusses the related work. Section 3 overviews background

Group-IKEv2 for multicast IPsec in the internet of things 3

concepts and protocols leveraged by Group-IKEv2. InSection 4, we describe our protocol Group-IKEv2.Section 5 presents an experimental performance evaluationof Group-IKEv2 on resource-constrained IoT devices, basedon our implementation for the Contiki OS. Finally, inSection 6, we draw our conclusive remarks.

2 Related work

Previous works have addressed secure groupcommunication at different communication layers. Thespecific layer where security is enforced typically dependson application requirements and device capabilities.

The IEEE 802.15.4 Standard (IEEE Computer Society,2016) provides also secure group communication at the linklayer, based on a commonly shared group cryptographickey. Also, many commercial resource-constrained platformsprovide compliant security operations via hardware.However, as link-layer security is enforced hop-by-hop,messages are decrypted and re-encrypted at each networknode along the path between the original sender andthe final recipient. This considerably impacts on messagedelivery time and network performance, together with thenon negligible overhead in terms of energy consumption(Daidone et al., 2011). Finally, IEEE 802.15.4 and otherlink-layer protocols do not consider the establishment andmanagement of cryptographic keys, while entrusting suchservices to the higher layers.

In Tiloca (2014) and Tiloca et al. (2017) propose asolution that enables secure group communication in IoTnetworks based on the datagram transport layer security(DTLS) protocol (Rescorla and Modadugu, 2012). Theproposed adaptation of DTLS secures communicationsin a multicast group, by using a pre-established GSAincluding common key material shared among the groupmembers. Specifically sender nodes protect multicastrequest messages by using the common group key material.Then, listener nodes may reply back with individualresponses, protecting them by means of individual keyingmaterial derived from the common group key materialand the ID of the sender node they reply to. However,such an approach does not support dynamic establishmentof GSAs and common key material, and does notprovide any particular policy enforcement on exchangedmessages. Instead, the Group-IKEv2 protocol proposed inthis paper enables the dynamic establishment of IPsecGSAs, and preserves the filtering of incoming/outgoingIPsec traffic enforced through group IPsec policies. Moregenerally, DTLS takes place on the transport layer, andprovides the same security assurances of the transport layersecurity (TLS) protocol, supporting peer-to-peer securecommunication over unreliable transport protocols such asUDP. However, security enforced at the transport layerdoes not protect network-layer related information, andthus it leaves room to network-layer attacks such as IPspoofing. Also, when relying on TLS, applications cannotbe totally unaware of the used multicast DTLS-based

solution. Instead, an approach based on multicast IPsec canbe totally agnostic of running applications.

The document (Canetti et al., 2005) describes theprinciples, requirements and features of group keymanagement schemes. In particular, it defines themechanisms that such schemes should provide and enforceduring group membership changes. Furthermore, it assertsthat the group key distribution algorithms should bescalable and able to minimise message exchanges in thegroup. Efficient and highly scalable group key managementschemes include, for instance (Harder and Wallner, 1999;Wong et al., 2000; Liu et al., 2009; Dini and Savino, 2011;Dini and Tiloca, 2013; Tiloca and Dini, 2016).

In Porambage et al. (2015) proposed two keyestablishment protocols for IoT networks, based on ellipticcurve cryptographic (ECC) operations. The first protocolis an improved version of Lee et al. (2011) solving theman-in-the-middle problem, while the second one is afurther improved version with elliptic curve integratedencryption scheme. The key derivations also implicitlyauthenticate group members, as relying on asymmetriccryptography based on the group members’ public andprivate keys. However, the proposed approach does notdiscuss how it can be possibly integrated and used inany standardised group communication protocol. Instead,the Group IKE-v2 protocol presented in this paper directlysupports multicast IPsec (see Section 3) and accommodatesby design different schemes for revocation and renewal ofgroup cryptographic material.

Our protocol Group-IKEv2 builds on a previous groupadaptation of IKEv2 described in the internet draft(Weis and Smyslov, 2018), which also supports dynamicallocation and provisioning of IPsec GSAs and relatedgroup key material. However, the work in Weis andSmyslov (2018) is not designed as particularly oriented toresource constrained IoT devices. In contrast, Group-IKEv2simplifies and optimises message structure and informationencoding, hence limiting communication overhead andimpact on performance. This makes it suitable to IoTscenarios, especially where both the regular IPsec groupmembers and the centralised Key Manager entity areresource-constrained devices. Furthermore, the proposalin Weis and Smyslov (2018) does set the ground forsupporting different group key management schemes, butdoes not specifically include a scheme that rekeys thegroup upon membership changes, and that at the sametime preserves backward and forward security. In contrast,Group-IKEv2 includes also a full-fledge group rekeyingscheme that securely updates the GSA and group keymaterial both periodically and upon membership changes,while preserving backward and forward security, as wellas strictly ensuring source authentication or rekeyingmessages. Finally, Group-IKEv2 comes with a prototypeimplementation for the Contiki OS, that we used to evaluateperformance on real IoT devices (see Section 5).

Finally, Felde et al. (2017) presented minimal G-IKEv2as an adaptation of Weis and Smyslov (2018). In particular,minimal G-IKEv2 has been implemented for the RIOTOS (RIOT, 2017), considering resource-constrained devices

4 K. Rizki et al.

as group members, but instead a Cisco CSR1000v serveracting as centralised group manager. Furthermore, minimalG-IKEv2 considers only the GSA establishment phasebetween the group manager and a candidate group member,but it does not cover the rekeying process for renewing thegroup key material. Moreover, Felde et al. (2017) providesonly a basic performance evaluation, considering only onecandidate member intending to join the group, and onlythe transmission and processing of minimal G-IKEv2 singlemessages. Instead, our protocol Group-IKEv2 includes alsoa full group rekeying procedure, is implemented for theContiki OS, and tested on both the group manager andthe group member side as resource-constrained platforms.In addition, our comprehensive performance evaluationof Group-IKEv2 considers different numbers of candidatemembers attempting to join the group, both the join processand the group rekeying process, as well as the overall timeand energy required to complete such processes.

3 Background

This section overviews background technologies referred inthe paper. Specifically, we survey the IPsec suite, the IKEv2protocol, and the multicast IPsec extension.

3.1 Internet protocol security

IPsec (Seo and Kent, 2005) is a protocol suite that providessecure communication at the network layer in IP networks.IPsec ensures message confidentiality and integrity, dataorigin authentication, replay attack protection and accesscontrol to IP packets. The feasibility and practicality ofIPsec was previously shown for 6LoWPAN, a network oflow-power IPv6-connected IoT devices (Raza et al., 2011).It was also shown that, in multi-hop 6LoWPAN networks,IPsec is more efficient than the previous state-of-the-artIEEE 802.15.4-based security (Raza et al., 2014). To protectIP traffic, communication parties establish a shared IPsecSA, which contains information such as cryptographic keymaterial, cryptosuite parameters and security policies. TheSA is identified by a security parameter index (SPI), andcan be set statically by an administrator or dynamicallyby means of a key management protocol, such as IKEv2(Kaufman et al., 2014).

In particular, IPsec provides two security protocols,namely authentication header (AH) (Kent, 2005a) andencapsulating security payload (ESP) (Kent, 2005b). Also,it can operate in two modes, namely transport and tunnel,which are both supported by AH and ESP. In transportmode, the IP packet is processed as is without changingits IP header, while in tunnel mode the whole original IPpacket is encapsulated into a new one.

An IPsec node maintains the following databases.

• The security policy database (SPD) contains thepolicies applied to the IPsec traffic. Each incomingand outgoing IPsec packet is checked against theSPD, which is divided into the three parts SPD-S

(secure traffic), SPD-I (inbound) and SPD-O(outbound). Each SPD entry specifies the action toperform on the matching traffic, i.e., DISCARD,BYPASS, or PROTECT. In case of PROTECT action,the SPD entry indicates the specific SA to considerfor processing the IPsec packet.

• The security association database (SAD) contains theactive SAs. When an IPsec packet matches aPROTECT entry in the SPD, the SPI in the packet isused to access the SAD and retrieve the SA forprocessing that packet.

• The peer authorisation database (PAD) provides a linkbetween the SPD and the SA establishment protocol,e.g., IKEv2. The PAD contains information on thenetwork nodes authorised to communicate with theIPsec node, as well as the protocol and method to usefor authentication. When an IPsec packet has to beprotected but no SA is found, the sender (recipient)node checks in the PAD whether the recipient (sender)peer is authorised to communicate through IPsec. Ifso, a new SA can be dynamically established bymeans of the IKEv2 protocol (Kaufman et al., 2014).

Figure 1 Processing of IPsec inbound traffic

Figure 1 overviews the processing for inbound IPsec traffic.Upon receiving an IPsec packet, the recipient node looks fora match in SPD-I and SPD. If a security policy admittingincoming traffic is not found, the packet is discarded.Otherwise, the recipient node looks for a correspondingSAD entry. If a valid SA is found, it is used to processthe packet. Otherwise, the PAD is checked to assertif the sender node is an authorised IPsec peer, beforeestablishing a new SA through IKEv2 (or any alternativekey management protocol). Similar considerations hold foroutbound IPsec traffic.

3.2 Internet key exchange version 2

In order to dynamically establish SAs, IPsec typically relieson the key management protocol IKEv2 (Kaufman et al.,2014).

As shown in Figure 2, first the two parties exchangetwo messages IKE SA INIT to establish an IKE SA, whichis used to protect further IKEv2 communication. Thesemessages include the supported cryptographic suites, noncesand other information used in the next steps, such as themodes to protect following IKEv2 messages. Then, thetwo parties exchange two secured messages IKE AUTH,

Group-IKEv2 for multicast IPsec in the internet of things 5

according to the pre-shared key (PSK) or the certificateauthentication mode. The former requires the parties topre-share a cryptographic symmetric key, typically providedby out-of-band means. The second mode results in theparties exchanging their public certificates. Through thissecond exchange, the two parties: authenticate each otherand the previous messages; and establish a child SA. Thechild SA is generated and negotiated by using the IKE SA,and is used to protect the actual IPsec traffic. The IKE INITand IKE AUTH exchanges must be successfully completedbefore further exchanges occur. Finally, INFORMATIONALmessages are used to report errors, or to inform of the statusand deletion of SAs.

Figure 2 Message exchange in IKEv2

3.3 Multicast IPsec

In IP multicast, a sender can transmit single packetsaddressed to multiple recipients. Both senders and recipientsexplicitly register as members of a same group associatedto a multicast IP address. The exact format of multicastaddresses are specifically defined by IPv4 and IPv6. Thisgroup communication model displays particularly efficientperformance, since multiple recipients can be reached atonce by transmitting a single multicast message. Thispractically results in reduced communication overhead andenergy consumption.

Multicast IP communication can be secured with IPsec.In fact, Gross et al. (2008) specifies multicast IPsec, anextension enabling IPsec to protect IP packets in groupcommunication contexts. That is, the same IPsec databasesintroduced in Subsection 3.1 are extended as:

1 group security policy database (GSPD), also similarlydivided into three parts

2 group security association database (GSAD)

3 group peer authorisation database (GPAD).

These are used to process unicast and multicast traffic inthe group.

Besides, multicast IPsec introduces GSAs, whichaccordingly extend the SAs described in Subsection 3.1.The GSPD entries indicate in which direction(s) a GSAcan be used. In particular, the sender-only (receiver-only)direction refers to the GSA usage for the outbound(inbound) traffic. Instead, the symmetric direction signalsthat the GSA can be used for both inbound and outboundIPsec traffic. The GPAD includes also information about

possible Group Controllers as units responsible for thegroup, as well as the valid methods to authenticate them.

4 Group-IKEv2

This section describes our group key management protocolGroup-IKEv2. The protocol provides dynamic and flexibleestablishment of GSAs for multicast IPsec, as well asa full-fledge scheme that renews IPsec GSAs and groupkey material, both on a periodical fashion and upongroup membership changes, while preserving backward andforward security in the group.

Group-IKEv2 is designed with IoT requirements inmind, considering scenarios where both regular IPsec groupmembers and the GC/KS are resource-constrained devices.This practically reflects in a number of design choices, asto efficient format and encoding of exchanged messages, inorder to limit the impact on communication overhead andperformance (see Subsection 4.3).

Figure 3 Example of Group-IKEv2 network scenario(see online version for colours)

We refer to the network scenario depicted in Figure 3, anddenote by GC/KS the centralised entity responsible for themulticast IPsec group, i.e., for managing the GSAs, keymaterial and group membership. This includes handling thejoining process of new group members, and renewing thegroup key material both periodically or upon membershipchanges. The GC/KS is also configured as a memberof the groups it manages, and maintains informationabout the nodes authorised to join the group in its ownGPAD. Specific methods to provide the GC/KS with suchauthorisation information and to accordingly enforce accesscontrol are out of the scope of this paper.

Furthermore, we denote by candidate member a networknode that intends or is in the process to join the multicastgroup. Finally, we denote by current member a networknode which is fully operative as member of the multicastgroup. In the rest of the paper, we assume that all networknodes intending to join a multicast group: support multicastIPsec; know the multicast IP address of the group; storepredefined group policies in their GSPD as well as the IPaddress of the GC/KS responsible for the group in theirGPAD.

Table 1 summarises the key material stored bygroup members. Group-IKEv2 considers two kinds ofcryptographic keys, i.e., keys encrypting keys (KEKs) andtraffic encrypting keys (TEKs). That is, KEKs are usedto protect the Group-IKEv2 key management messages,

6 K. Rizki et al.

according to a GSA KEK. Instead, TEKs are used to protectthe actual IPsec traffic within the multicast group, accordingto a GSA TEK. In addition to the GSAs associated to themulticast group, each current member stores:

1 the public key of the GC/KS, either pre-installedbefore joining the group or retrieved from trustedparties

2 a pairwise symmetric key, namely node key, secretlyshared only with the GC/KS.

The node key can be either pre-installed on the candidatemember before its joining, or generated and provided by theGC/KS during the joining process.

Table 1 Key material at a group member

Name Description

Key encryption Administrative keys forkeys (KEKs) securing key managementTransport encryption Administrative keys forkeys (TEKs) securing IPsec data trafficGC/KS public key Public key of the

GC/KS (pre-available)Node key Pairwise symmetric key,

shared with the GC/KS

Figure 4 Processing of multicast IPsec inbound traffic

Figure 4 overviews the message processing for inboundmulticast IPsec traffic, when Group-IKEv2 is used as groupkey management protocol. In particular, upon receivingan IPsec packet, the recipient node looks for a matchingentry in GSPD-I and GSPD. If a security policy admittingincoming traffic is not found, the packet is discarded.Otherwise, the recipient node looks for a correspondingGSAD entry. If a valid GSA is found, it is used toprocess the packet accordingly. Otherwise, i.e., the recipientnode is not a group member, the address of the GC/KSresponsible for the group is retrieved from the GPAD. Then,the recipient node contacts that GC/KS in order to join themulticast group.

Figure 5 overviews the exchanges of Group-IKEv2messages from a high-level network perspective. That is, anew candidate node willing to join the group contacts theGC/KS and performs the joining procedure. This essentiallyconsists in an exchange of IKE SA INIT messagesfollowed by an exchange of GSA AUTH messages. Thissecond exchange is interleaved by the join group rekeyingprocedure, where a GSA REKEY message is used to renewthe GSAs and group key material stored by the current

group members. Once the GSA AUTH exchange has beencompleted, the joining node fully becomes a member ofthe multicast group. Subsequently, further group rekeyingprocedures might be performed, either periodically or upona group member’s leaving. Figure 6 provides an example ofevent timeline, from the GC/KS perspective.

Figure 5 Message exchange in Group-IKEv2

Figure 6 Example of timeline on the GC/KS.

In the following, we describe the joining procedure andthe group rekeying procedure in Subsections 4.1 and 4.2,respectively.

4.1 The joining procedure

With reference to Figure 5 and the breakdown in Figure 7,the candidate member starts the joining procedure, bysending an IKE SA INIT request to the GC/KS, whichreplies with an IKE SA INIT response. After this firstexchange, the candidate member and the GC/KS agreeon the security parameters and cryptographic suite touse thereafter for protecting the following Group-IKEv2messages.

Figure 7 Breakdown of the join procedure

As a next step, a second exchange occurs, involvingtwo GSA AUTH messages. Similarly to the IKE AUTHmessages in IKEv2, these messages are used to authenticate

Group-IKEv2 for multicast IPsec in the internet of things 7

previously sent messages, exchange identities and establisha secure channel between the candidate member andthe GC/KS. In particular, the candidate member sends aGSA AUTH request to the GC/KS. The message includes agroup identification payload indicating the multicast IPsecgroup to join.

Upon receiving the GSA AUTH request, the GC/KSfirst accesses its GSPD and verifies that the group specifiedin the message is of its pertinence. Then, the GC/KSchecks its GPAD and verifies that the candidate member isauthorised to join the specified group. If it is not authorised,the GC/KS replies with an INFORMATIONAL messageand terminates the joining procedure. Otherwise, the GC/KSaccesses its GSAD and retrieves the GSA associated tothe multicast group. If the group is including at leastone current member, the GC/KS performs a join rekeyingprocedure by broadcasting a GSA REKEY message to thegroup, in order to install an updated GSA and new keymaterial on the current group members (see Subsection 4.2).

Finally, the GC/KS replies to the candidate memberwith a GSA AUTH response message, including the(updated) GSA and group key material. Upon receivingthe GSA AUTH response, the candidate member becomesa current member of the group and is fully operativeto participate in multicast IPsec communications with theother group members.

4.2 The group rekeying procedure

The GC/KS updates the GSA and key material in themulticast group according to a group rekeying procedure,by using GSA REKEY messages. In particular, the GC/KSrekeys the multicast group in a periodical fashion aswell as upon group membership changes, in order toensure backward and forward security (see Figure 5).The GSA REKEY messages are designed to accommodatedifferent group rekeying schemes for the actual delivery ofkey material to the group members. While Group-IKEv2is not devoted to any particular one, in the following werefer to a simple, yet secure and complete, group rekeyingscheme that ensures backward and forward security in thegroup.

Firstly, the GC/KS regularly rekeys the group accordingto a pre-defined period interval. To this end, the GC/KSbroadcasts a single GSA REKEY periodic message to thegroup. This message is protected with the current KEK,and carries only the new TEKs, together with updatedTEK-related information.

Secondly, the GC/KS performs a join rekeyingprocedure each time a new candidate member joins thegroup. The GC/KS performs the join rekeying procedureby broadcasting a single GSA REKEY join message. Thismessage is protected with the current KEK, and carriesboth the new KEK and the new TEK, together withupdated KEK- and TEK-related information. As shown inFigures 5 and 7, the GC/KS rekeys the group after havingreceived the GSA AUTH request and before replying withthe GSA AUTH response. By doing so, backward security

is ensured, i.e., the candidate member is not able to accessgroup communications occurred before its join.

Thirdly, the GC/KS performs a leave rekeying procedureeach time a current member leaves the group. Thisprocedure consists of two steps. First, the GC/KS sendsone unicast GSA REKEY Leave1 message separately toeach of the remaining current group members. Each ofthese messages is encrypted with the node key associatedto the intended recipient and carries the new KEK, togetherwith updated KEK-related information. After that, theGC/KS broadcasts a single GSA REKEY Leave2 message.This message is protected with the just established newKEK, and carries the new TEK, together with updatedTEK-related information. By doing so, forward security isensured, i.e., the leaving group member is not able to accessfurther group communications occurring after its leaving orto participate to future rekeying instances. Table 2 providesa high-level breakdown of the tree rekeying procedures.

Table 2 Rekeying procedures in Group-IKEv2

Distributed Secured Transmittedcontent with messages

Periodic New TEK Current 1 broadcastrekeying material KEKs to the groupJoin New KEK and Current 1 broadcastrekeying TEK material KEKs to the groupLeave New KEK Node key of 1 unicast perrekeying material the recipient non-leaving

(step 1) member memberNew TEK New KEKs 1 broadcastmaterial provided at to the group(step 2) step 1

The GC/KS ensures source authenticity of all GSA REKEYmessages. In particular, all rekeying messages butGSA REKEY Leave1 are signed by means of the GC/KSprivate key. GSA REKEY Leave1 messages are alreadysource authenticated, as protected with the pairwise nodekey secretly shared between the GC/KS and the groupmember intended as recipient.

4.3 Differences from previous approaches

Our protocol Group-IKEv2 builds on a previous proposaldescribed in the internet draft (Weis and Smyslov, 2018).At design time, we especially referred to its version 12.Now that Group-IKEv2 has been described, we are in theposition to point at specific differences with respect to(Weis and Smyslov, 2018).

First of all, Group-IKEv2 has been designed to beconvenient and deployable also in IoT scenarios where alldevices are resource-constrained, including the GC/KS. Tothis end, the following design choices were taken withrespect to the GSA AUTH exchange between a candidatemember and the GC/KS (see Subsection 4.1).

• The list of authorised recipients is not providedthrough the substructures destination traffic selector

8 K. Rizki et al.

of the GSA KEK and GSA TEK payloads. In fact,the implicit and only authorised recipient coincideswith the multicast IP address of the IPsec group.

• The list of authorised senders of key managementtraffic, i.e., of GSA REKEY messages, is notprovided through the substructures source trafficselector of the GSA KEK payload. In fact, theimplicit and only authorised sender coincides with theIP address of the GC/KS.

• The list of authorised senders of multicast IPsectraffic, i.e., the addresses of the current groupmembers, is not provided in the substructures sourcetraffic selector of the GSA TEK payload. In theoriginal specification, such lists follows a rangeformat, i.e., they indicate a pool of authorisedaddresses between a start and an end value. However,this has two disadvantages. First, it induces groupmembers to populate their policy and authorisationdatabases in a coarse-grain fashion. Second, itpractically requires the inclusion of multiple sourcetraffic selector payloads in the same GSA AUTHresponse, i.e., one for each different subnetcomprising authorised IPsec traffic sources, withconsequent considerable impact on the overallmessage size. This is indeed the case for IoT devicesdirectly exposed to the internet. In contrast,Group-IKEv2 provides the exact list of authorisedIPsec traffic sources in a new compact sender IDpayload, of which a single instance is included in theGSA AUTH response.

• The lifetime of the GSA TEK is not explicitlyincluded. Instead, it is implicitly assumed to be thesame as the specified lifetime of the GSA KEK. TheGSA TEK key material is renewed anyway right afterthe renewal of the GSA KEK material, either due toits expiration or if it gets compromised (or theGC/KS suspects so).

The simplified and optimised GSA AUTH messagedescribed above makes it possible to exchange a reducedamount of information, and allows both candidate membersand the GC/KS to perform a more efficient Join Procedureupon joining a multicast IPsec group.

Secondly, Group-IKEv2 includes and provides in anintegrated way a full-fledge group key management scheme,whose details are provided in Subsection 4.2. In particular,it is worth emphasising the following points.

• The included rekeying scheme effectively rekeys thegroup on a regular basis as well as upon asynchronousmembership change events, i.e., a member’s joiningor leaving. When doing so, it especially preservesbackward and forward security in the IPsec group. Ofcourse, the possibility to replace this specific rekeyingscheme with alternative ones is preserved.

• For each sent rekeying message, source authenticity isstrictly ensured, either through a digital signature

included by the GC/KS or by means of the pairwiseSA between the GC/KS and the particularly addressedgroup member.

• The join rekeing procedure is an integral part of thebroader joining procedure. That is, as part of thejoining procedure itself, the GC/KS rekeys the IPsecgroup before sending a GSA AUTH response to thecandidate member. This is the crucial step thatensures backward security in the IPsec group.

5 Experimental evaluation

We implemented Group-IKEv2 for the Contiki OS (Contiki,2017) and released it as open source software availableonline at Rizki (2017). Then, we considered a setupwhere a GC/KS manages a multicast IPsec group throughGroup-IKEv2. The GC/KS as well as the group membersare resource-constrained devices from the OpenMoteplatform (OpenMote, 2017) and equipped with the CC2538radio chipset (Texas Instruments, 2017), 32 kB of RAMand 512 kB of flash ROM. The considered devices ranContiki and formed an IEEE 802.15.4 wireless network(IEEE Computer Society, 2016). The communication stackis further composed of 6LoWPAN, uIP, multicast IPsec and,finally, Group-IKEv2 running over UDP.

Unless otherwise indicated, we considered the followingsettings. We used the AES-CCM cipher with 16-byte keys(Housley, 2005), a pseudo random function (PRF) based onHMAC-SHA256 (Schiller, 2005), SHA-2 as hash functionand ECC-based signatures for source authentication. Allcryptographic operations were performed in hardware asprovided by the CC2538 chipset. Furthermore, the IPsectraffic in the multicast group was protected by means ofthe ESP security protocol. In particular, the GSPD enforcedthe BYPASS policy over the ICMPv6 and Group-IKEv2traffic, as well as the PROTECT policy over other kindof data within the multicast group. Finally, each candidatemember has pre-installed the public key of the GC/KS anda pairwise node key shared only with the GC/KS. Also, theGC/KS stores all such pairwise node keys.

In our evaluation, we considered different numbers ofcandidate members joining the multicast group, rangingfrom 1 to 5. In particular, all the considered candidatemembers became activated at the same time and started tointeract with the GC/KS to join the multicast IPsec group.Specifically, we considered the authentication process ofcandidate members with the GC/KS as based either onPSKs or certificates, as the two modes available in theContiki implementation of IPsec. Also, the GC/KS rekeyedthe multicast group before finalising the join of eachpending candidate member (see Subsection 4.2). For eachexperiment, we performed 25 independent repetitions andaveraged experimental results over all repetitions.

The following experimental results encompass:

1 memory consumption and message size

Group-IKEv2 for multicast IPsec in the internet of things 9

2 energy consumption for joining and rekeying thegroup

3 time required to rekeying the group

4 time required to fully set up the group.

When measuring energy consumption, we consideredthree different contributions, i.e., the energy spent bythe CPU, and by the radio interface in transmission orreception mode. In particular, we computed each of thesecontributions as the product between the related powerconsumption (Texas Instruments, 2017) and the relatedactive time collected by using the energest frameworkprovided in Contiki. This is a common and consolidatedpractice in evaluative research/engineering works involvingconstrained IoT devices. Besides, energest has been provento accurately estimate energy consumption, while increasingthe computing time only of the 0.7% (Dunkels et al., 2007).Besides, we considered the worst case when devices donot leverage the radio duty cycling mechanism provided inContiki (2015) for switching off the radio interface whennot in use. That is, the radio interface is by default on andin reception mode.

Note that, despite obvious advantages in terms ofenergy saving, duty cycling results also in non negligiblepacket loss, which can significantly worse communicationperformance. The proper tuning of energy savingmechanisms is actually related to network performanceoptimisation, and hence is out of the scope of this paper.Finally, note that collected energy measurements of coursedepend on the specifically tested implementation, forwhich optimisations are possible. However, the sameimplementation has been used over the different testsettings, hence respective results are mutually consistentand comparable with each other.

5.1 Memory and message size

Figure 8 shows the memory consumption for the GC/KSand a candidate member (client), in the presence ofGroup-IKEv2. With reference to the memory usage onthe GC/KS, 44,000 B (15,668 B) of flash (RAM) aredue to other software components than Group-IKEv2, e.g.,Contiki, the communication stack, and the main application.Similarly, 44,208 B (15,728 B) of flash (RAM) on acandidate member are due to other software componentsthan Group-IKEv2.

As shown in Figure 8, both the GC/KS and thecandidate member display a higher consumption of flashmemory when the Certificate mode is used, due to thestorage of certificate-related information. Similarly, thememory consumption increases with the maximum allowednumber of group members, due to the greater amount ofinformation to store both on the GC/KS and the candidatemembers. Also, given an authentication mode and a numberof candidate members, the GC/KS consumes less flashmemory than a joining candidate member.

Furthermore, the consumption of RAM memory displaysa trend which is similar to what observed for the Flash

memory. However, both for the GC/KS and candidatemembers, we observe no difference in case either the PSKor the Certificate mode is used when joining the multicastgroup.

Figure 8 Memory consumption for GC/KS and candidatemember (client) (see online version for colours)

The adopted authentication mode considerably affectsalso the size of messages exchanged between candidatemembers and GC/KS during the joining procedure. Inparticular, the PSK mode results in 168 (160) B for eachIKE INIT SA request (response) and 148 (368) B for eachGSA AUTH request (response). Instead, the Certificatemode results in 168 (185) B for each IKE INIT SA request(response) and 540 (736) B for each GSA AUTH request(response).

Finally, a GSA REKEY message sent by the GC/KSto rekey the group displays the following size, dependingon the specific rekeying event: 192 B for the Periodicrekeying message; 300 B for the join rekeying message; 160B (192 B) for message Leave1 (Leave2) in case of leaverekeying.

5.2 Energy consumption of the joining procedure

This section presents results on energy consumption whenperforming the joining procedure. One can foresee resultsaligned to a number of trends, according to the followingcomplexity oriented analysis.

A candidate member performing the joining procedurehas to process and exchange with the GC/KS an amount ofinformation which is affected by:

1 the specific authentication mode, i.e., the PSK modeis lighter than the certificate mode to carry out

2 the competitive access to the medium shared withother candidate members, i.e., the resolution ofmedium access contention in IEEE 802.15.4, whosedetails are out of the scope of this work.

Also, the more concurrent candidate members, the morejoin rekeying procedures the GC/KS performs overall,so making the joining procedure of the latest candidatemembers admitted to the group much longer. Thesecontributions affect the overall duration of the joinprocedure, and hence the energy spent when performing it.We recall that devices do not rely on any radio duty cyclingmechanism, and hence keep their radio interface on and inRX mode by default.

10 K. Rizki et al.

The size of exchanged messages may vary dependingon the specific key management scheme in the group,and hence the related administrative key material to beprovided to a candidate member upon its joining. For thescheme considered in this work, such a message overheadis constant. Complexity of actual cryptographic operationsdepends on the specific cypto primitives used on the nodes.Those are up to the specific ones prescribed by, in thiscase, IPsec and IKEv2, and are out of the scope of thiswork. Therefore, one expects any candidate group memberto consume during the join procedure an amount of energythat linearly grows with the number of concurrent candidatemembers, due to relevant contributions from the CPU andthe radio interface.

On the other hand, the GC/KS has most simply toperform n joining procedures and (n− 1) interleavedjoin rekeying procedures, given n concurrent candidatemembers joining a newly created group. Similarly to whatdiscussed above, the overall process takes longer in thepresence of more candidate members, with consequentgreater energy consumption. Therefore, one expects theGC/KS to consume an amount of energy that, in all itscontributions, grows linearly with the number of concurrentcandidate members to be admitted to the group.

The analytical trends discussed above are consistentwith the experimental results presented and discussed in therest of this section.

Figure 9 Energy consumption during the joining procedure(see online version for colours)

Figure 9 shows the average energy consumption duringthe joining procedure, on the GC/KS and on a candidatemember. On the GC/KS, the energy consumption ismeasured from when the GC/KS receives the firstIKE INIT SA request to when the GC/KS sends the lastGSA AUTH response. On a candidate member, it ismeasured from when it starts the joining procedure towhen that candidate member has successfully processed theGSA AUTH response.

With one candidate member, the GC/KS consumes109.34 mJ (252.16 mJ) when the PSK (certificate)authentication mode is considered. On the other hand,the candidate member consumes 108.65 mJ (251.47 mJ)when the PSK (certificate) authentication mode is used.Instead, with five candidate members, the GC/KS consumes1,648.21 mJ (1,689.68 mJ) when the PSK (certificate)authentication mode is used. On the other hand, a candidatemember consumes 395.09 (579.50) mJ when the PSK(certificate) authentication mode is used.

That is, the overall consumed energy increases withthe number of candidate members. On the GC/KS, thisis simply due to the larger number of candidate membersthat intend to join the multicast group, and hence resultsin a larger amount of time to complete all the joiningprocedures. On the candidate members, this is mostly dueto the contention with the other candidate members foraccessing the physical medium and communicating withthe GC/KS. This mostly determines the order according towhich the candidate members actually join the group. Also,note that each of the contributions to energy consumptiondue to the CPU and the radio interface in RX or TX modegrows with the number of candidate members.

Furthermore, both the GC/KS and candidate membersdisplay a higher energy consumption when the certificatemode is used, due to the more complex authenticationprocessing compared to the PSK mode, i.e., the processingof the other party’s certificate and possible exchangeof certificate information. Finally, we also observe that,given an authentication mode and a number of candidatemembers, a candidate member joining the multicast groupconsumes less energy than the GC/KS.

5.3 Group rekeying

This section presents results on energy consumption andtime spent when performing the group rekeying procedures.With reference to energy consumption, one can foreseeresults aligned to a number of trends, according to thefollowing complexity oriented analysis.

The rekeying process strictly depends on the specificgroup key management scheme used in the group. For theone considered in this work, each of the current groupmembers receives the same number of messages from theGC/KS, and processes a same amount of information whichis constant and not affected by the group size. Also, werecall that devices do not rely on any radio duty cyclingmechanism, i.e., they keep their radio interface on and inRX mode by default. Finally, current group members donot reply to the GC/KS during any rekeying procedure.Therefore, one expects any current group member toconsume:

1 about the same amount of energy during a periodicrekeying or join rekeying

2 about the same amount of energy regardless the groupsize, during a leave rekeying.

On the other hand, the GC/KS processes and sends onerekeying message of constant size for both the periodicrekeying and join rekeying procedure. Instead, whenperforming the leave rekeying, it processes and transmits anumber of constant-size rekeying messages which linearlyincreases with the current group size. Therefore, oneexpects the GC/KS to consume:

1 about the same amount of energy during a periodicrekeying or join rekeying

Group-IKEv2 for multicast IPsec in the internet of things 11

2 an amount of energy that linearly grows with thenumber of current members during a leave rekeying,especially due to the radio interface in TX mode.

Of course, the size of such exchanged group rekeyingmessages may vary depending on the specific keymanagement scheme, especially due to the relatedadministrative key material to be renewed in the group. Forthe scheme considered in this work, such a per-messageoverhead is constant. Complexity of actual cryptographicoperations depends on the specific cypto primitives used onthe network nodes. Also in this case, those are up to thespecific ones prescribed by, in this case, IPsec and IKEv2,and are out of the scope of this work.

The analytical trends discussed above are consistentwith the experimental results presented and discussed in therest of this section.

Figure 10 shows the average energy consumption duringthe group rekeying procedure, on the GC/KS and on acurrent group member. We consider the three cases periodicfor the periodic rekeying, join for the join rekeying,and leave for the leave rekeying, consistently with theprocedures described in Subsection 4.2.

Figure 10 Energy consumption during the rekeying procedure(see online version for colours)

For the GC/KS, the energy consumption is measured fromwhen the GC/KS generates the first rekeying message towhen the GC/KS has sent the last rekeying message. For acurrent member, the energy consumption is measured fromwhen it has received the first rekeying message to whenthat current member has been rekeyed, i.e., when it hasinstalled the new group key material. Note that, duringany of the rekeying procedures, the current members onlyreceive GSA REKEY messages from the GC/KS, and donot reply back. Therefore, the rekeying procedures do notresult in the current members consuming energy in radioTX mode. For the periodic and join cases, a multicastgroup of five members is considered. For the leave case,we consider a multicast group whose size ranges from twoto five members.

In the periodic case, the GC/KS (a current member)consumes 16.24 mJ (30.65 mJ), regardless the groupsize. In the join case, the GC/KS (a current member)consumes 16.80 mJ (30.67 mJ), regardless the groupsize. In the leave case, the GC/KS consumes 34.85 mJ(39.55 mJ) in the presence of 2 (5) group members. Also,regardless the group size, every current member consumes

on average 61.87 mJ, within a ±0.21% range due to minormeasurement variations observed during the experiments.

The energy consumed on the periodic case is thesmallest among all rekeying cases. In fact, since thereis no membership change, only GSAT-related informationrequires update, and hence the GC/KS sends only one smallrekeying message. In the join case, the energy consumed isslightly higher than in the periodic case. In fact, due to themembership change, the GC/KS sends one larger rekeyingmessage including also GSAK-related updated information.Similar considerations hold on the current member side,although the difference between the periodic case and thejoin case is even smaller.

In the leave case, the GC/KS sends multiple Leave1messages and one single Leave2 message to the group.Hence, the energy consumed is higher than in the other tworekeying cases, i.e., more than twice the energy consumedfor the considered group sizes. In particular, the overallenergy consumed on the GC/KS increases with the numberof current group members. This is due to the generationand transmission of more Leave1 messages, each addressedto a different current member. Instead, the overall energyconsumed on a group member is negligibly affected by thegroup size. In fact, each rekeyed node in the group receivesthe same number of rekeying messages and processes onlytwo of them. Finally, for the considered group sizes, theGC/KS consumes less energy than a group member.

Figure 11 Group rekeying time (see online version for colours)

Figure 11 shows the overall time required to rekey themulticast group, separately for the three different casesperiodic, join and leave. Specifically, the group rekeyingtime is measured from when the GC/KS generates the firstrekeying message to when all the rekeyed group membershave installed the new key material. Also, Figure 11highlights the key distribution time spent by the GC/KS tocomplete the group rekeying. That is, the key distributiontime is measured from when the GC/KS generates the firstrekeying message to when the GC/KS has sent the lastrekeying message.

In the periodic case, the group rekeying time is 2.24 s,while the key distribution time is 0.77 s. In the join case,the group rekeying time is 2.26 s, while the key distributiontime is 0.80 s. In the leave case, the group rekeying timeis 2.30 s (2.42 s) in the presence of 2 (5) group members,while the key distribution time is 0.85 s (0.96 s) in thepresence of 2 (5) group members. As to the differences

12 K. Rizki et al.

between the three rekeying cases, similar considerationshold with respect to the discussion above about energyconsumption.

5.4 Total group setup time

Figure 12 shows the total group setup time for differentnumbers of candidate members, i.e., the time required tofully set up a multicast group through Group-IKEv2. Weassume that:

1 the group is initially empty

2 all candidate members start the joining process at thesame time

3 the GC/KS performs a join group rekeying beforesending the GSA AUTH message to the currentlyserved candidate member.

Figure 12 Total group setup Time (see online versionfor colours)

In the presence of one candidate member, the total groupsetup time is 17.9 s (21.46 s) when the PSK (certificate)authentication mode is used. Note that in this case theGC/KS does not perform any join group rekeying. Inthe presence of five candidate members, the total groupsetup time is 87.25 s (91.01 s) when the PSK (certificate)authentication mode is used. Note that, during that time, theGC/KS performs four join rekeying procedures, which take9.17 s in total.

Furthermore, given an authentication mode, the totalgroup setup time increases with the number of candidatemembers, due to the following reasons. On one hand,the GC/KS has to perform more Group-IKEv2 exchanges,which are in turn influenced by more candidate memberscontending for accessing the medium. Also, the GC/KS hasto perform a higher number of join group rekeying. Finally,given a number of candidate members, the total group setuptime is higher when the certificate mode is used, due to themore complex authentication processing compared to thePSK mode.

6 Conclusions

We have presented Group-IKEv2, an adaptation of theIKEv2 standard key establishment protocol to enable

IPsec secure communications in multicast groups. Theprotocol has been designed to be affordable also in IoTscenarios composed of resource-constrained devices only.In particular, Group-IKEv2 makes it possible for groupcandidate members to securely receive key material froma centralised group controller upon joining, and hencebecome fully operative members of an IPsec multicastgroup. Furthermore, Group-IKEv2 includes a full-fledgegroup key management scheme, that enables the groupcontroller to renew the key material in the group, both ina periodical fashion and upon a group membership change,while preserving backward and forward security in theIPsec group. We have implemented Group-IKEv2 for theContiki OS and experimentally evaluated its performancein an IEEE 802.15.4 network of resource-constrained IoTdevices. Results show that, under different configurationsand number of candidate group members, Group-IKEv2is affordable also for resource-constrained platforms andhence effectively deployable to enable IPsec groupcommunication in IoT scenarios. Future works will focus onthe integration and comparison of different group rekeyingschemes into Group-IKEv2, and its performance evaluationin alternative resource-constrained platforms.

Acknowledgements

The authors sincerely thank the anonymous referees andthe associate editor for their insightful comments andsuggestions. This work has received funding from theEuropean Union’s Seventh Framework Programme forresearch, technological development and demonstrationunder grant agreement no. 607109. This work wasalso supported by the EIT-Digital High Impact InitiativeACTIVE.

References

Canetti, R., Dondeti, L.R., Lindholm, F. and Baugher, M.(2005) Multicast Security (MSEC) Group Key ManagementArchitecture, RFC 4046.

Contiki (2015) Radio Duty Cycling – Contiki Wiki [online]https://github.com/contiki-os/contiki/wiki/Radio-duty-cycling(accessed October 2018).

Contiki (2017) Contiki: The Open Source OS for the Internetof Things [online] http://www.contiki-os.org/ (accessed October2018).

Daidone, R., Dini, G. and Tiloca, M. (2011) ‘On experimentallyevaluating the impact of security on IEEE 802.15.4 networks’,in 3rd International Workshop on Performance Control inWireless Sensor Networks, PWSN 2011, pp.20–25.

Dini, G. and Savino, I.M. (2011) ‘LARK: a lightweight authenticatedreKeying scheme for clustered wireless sensor networks’, ACMTransactions on Embedded Computing Systems, Vol. 10, No. 4,pp.41:1–41:35.

Dini, G. and Tiloca, M. (2013) ‘HISS: a highly scalable schemefor group rekeying’, The Computer Journal, Vol. 56, No. 4,pp.508–525.

Group-IKEv2 for multicast IPsec in the internet of things 13

Dunkels, A., Osterlind, F., Tsiftes, N. and He, Z. (2007)‘Software-based on-line energy estimation for sensor nodes’,in Proceedings of the 4th Workshop on Embedded NetworkedSensors, EmNets’07, ACM, New York, NY, USA, pp.28–32.

Felde, N.G., Guggemos, T., Heider, T. and Kranzlmuller, D. (2017)‘Secure group key distribution in constrained environments withikev2’, in 2017 IEEE Conference on Dependable and SecureComputing, pp.384–391.

Gross, G., Weis, B. and Ignjatic, D. (2008) Multicast Extensions tothe Security Architecture for the Internet Protocol, RFC 5374.

Harder, E.J. and Wallner, D.M. (1999) Key Management forMulticast: Issues and Architectures, RFC 2627.

Housley, R. (2005) Using Advanced Encryption Standard (AES) CCMMode with IPsec Encapsulating Security Payload (ESP), RFC4309.

IEEE Computer Society (2016) IEEE Std 802.15.4-2015 – IEEEStandard for Low-Rate Wireless Networks.

Kaufman, C., Hoffman, P.E., Nir, Y., Eronen, P. and Kivinen, T.(2014) Internet Key Exchange Protocol Version 2 (IKEv2), RFC7296.

Kent, S. (2005a) IP Authentication Header, RFC 4302.Kent, S. (2005b) IP Encapsulating Security Payload (ESP), RFC

4303.Lee, C-Y., Wang, Z-H., Harn, L. and Chang, C-C. (2011) ‘Secure

key transfer protocol based on secret sharing for groupcommunications’, IEICE Trans. Inf. Syst., Vol. 94, No. 11,pp.2069–2076.

Liu, P., Lee, W-C., Gu, Q. and Chu, C-H. (2009) ‘KTR: an efficientkey management scheme for secure data access control inwireless broadcast services’, IEEE Transactions on Dependableand Secure Computing, Vol. 6, No. 3, pp.188–201.

OpenMote (2017) Open Hardware for the Industrial Internet ofThings, OpenMote.

Porambage, P., Braeken, A., Schmitt, C., Gurtov, A., Ylianttila, M.and Stiller, B. (2015) ‘Group key establishment for enablingsecure multicast communication in wireless sensor networksdeployed for iot applications’, IEEE Access, Vol. 3,pp.1503–1511.

Raza, S., Duquennoy, S., Chung, T., Voigt, T., Roedig, U. et al.(2011) ‘Securing communication in 6lowpan with compressedipsec’, in 2011 International Conference on DistributedComputing in Sensor Systems and Workshops (DCOSS), IEEE,pp.1–8.

Raza, S., Duquennoy, S., Hoglund, J., Roedig, U. and Voigt, T.(2014) ‘Secure communication for the internet of things – acomparison of link-layer security and IPsec for 6LoWPAN’,Security and Communication Networks, Vol. 7, No. 12,pp.2654–2668, Wiley.

Rescorla, E. and Modadugu, N. (2012) Datagram Transport LayerSecurity Version 1.2, RFC 6347.

RIOT (2017) RIOT – The Friendly Operating System for the Internetof Things [online] https://riot-os.org/ (accessed October 2018).

Rizki, K. (2017) Group-IKEv2 Implementation [online]https://github.com/krizki/Group-IKEv2 (accessed October 2018).

Schiller, J.I. (2005) Cryptographic Algorithms for Use in the InternetKey Exchange Version 2 (IKEv2), RFC 4307.

Seo, K. and Kent, S. (2005) Security Architecture for the InternetProtocol, RFC 4301.

Texas Instruments (2017) CC2538 A Powerful System-On-Chip for2.4-GHz IEEE 802.15.4-2006 and ZigBee Applications, TexasInstruments.

Tiloca, M. and Dini, G. (2016) GREP: A Group REkeying Protocolbased on Member Join History, in IEEE ISCC 2016, IEEE,pp.326–333.

Tiloca, M., Nikitin, K. and Raza, S. (2017) ‘Axiom – DTLS-basedsecure IoT group communication’, ACM Transactions onEmbedded Computing Systems, Vol. 16, No. 3, pp.1–29.

Tiloca, M. (2014) ‘Efficient protection of response messages inDTLS-based secure multicast communication’, in The 7thInternational Conference on Security of Information andNetworks (SIN 2014), pp.466–472.

Weis, B. and Smyslov, V. (2018) ‘Group key management usingIKEv2’, Internet-Draft draft-yeung-g-ikev2, Internet EngineeringTask Force, Work in Progress.

Wong, C.K., Gouda, M. and Lam, S.S. (2000) ‘Secure groupcommunications using key graphs’, IEEE/ACM Transactions onNetworking, Vol. 8, No. 1, pp.16–30.