# Securing SDN-Based IoT Group Communication
## 5 Related Research  
Many research efforts provide solutions for protecting the confidentiality of IoT group communication messages, e.g., using group object security for constrained restful environments (OSCORE) [24], DTLS with pre-shared keys among group members [25; 26], attribute-based encryption [27], or even by relying on the information-centric networking (ICN) paradigm [28]. These solutions are concerned with the establishment of a secret key that is used for encrypting data [24; 28] or the communication channels [25; 26]. Such a key can be derived by a pre-shared symmetric key, a public key, or by the attributes of the communicating endpoints. Our solution is orthogonal to these approaches since our goal is to make sure that a client receives CoAP responses only from authorized servers.  
Our work considers an SDN-based underlay architecture used instead of IP multicast for implementing group communication. Many related efforts are considering other alternatives to IP multicast, including the use of bit index explicit replication (BIRE) [29], MPL [30], and ICN [31]. We see these efforts complementary to our approach since our solution is agnostic to the underlying mechanism; therefore, it could be used with any of them.  
Some related solutions use identity-based signature (IBS) to achieve similar goals with our work (see, for example, [32]). Although IBS removes the need for public keys, it introduces computational overhead, and it suffers from the so-called key escrow problem, since there is a single entity (the key generator) that knows all private keys. Our solution uses Ed25519 keys, which are 32 bytes long; hence, the gains, in terms of communication overhead of using an identity rather than an Ed25519 key, are small.  
Our solution is designed for IoT devices and gateways that support the WoT specification. However, in recent years, a number of related technologies have emerged. For  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Operation** & **Desktop** & **Raspberry Pi** \\ \hline LDP & 174.6 ms & 999.2 ms \\ LDP verification & 74.3 ms & 1004.0 ms \\ \hline \hline \end{tabular}
\end{table}
Table 2: LDP generation and verification times when BBS+ is used.  
example, under the umbrella of the _European IoT Platform Initiative_ ([[https://iot-epi.eu/](https://iot-epi.eu/)]([https://iot-epi.eu/](https://iot-epi.eu/)) accessed on 5 August 2021) a number of IoT gateway technologies were developed, by projects such as symbIoTe ([[https://iot-epi.eu/project/symbiote/](https://iot-epi.eu/project/symbiote/)]([https://iot-epi.eu/project/symbiote/](https://iot-epi.eu/project/symbiote/)) accessed on 5 August 2021), AGILE ([[https://iot-epi.eu/project/agile/](https://iot-epi.eu/project/agile/)]([https://iot-epi.eu/project/agile/](https://iot-epi.eu/project/agile/)) accessed on 5 August 2021), and Interior ([[https://iot-epi.eu/project/inter-iot/](https://iot-epi.eu/project/inter-iot/)]([https://iot-epi.eu/project/inter-iot/](https://iot-epi.eu/project/inter-iot/)) accessed on 5 August 2021). These efforts are now stalled. Since the only requirement of our solution is that device descriptions are encoded using JSON, we believe that it can be easily adapted for other gateway technologies.  
Our system uses public keys for identifying IoT endpoints. A relevant technology that can be used instead is that of _decentralized identifiers_ (DIDs) [33]. DIDs are closely related to LDPs. Additionally, when applied to the IoT, DIDs have some interesting security and privacy properties [34].