Diet-ESP: IP Layer Security for IoT

Journal of Computer Security 0 (2017) 1 IOS Press

1

Diet-ESP: IP Layer Security for IoT Daniel Migault a , Tobias Guggemos b,∗ , Sylvain Killian c , Maryline Laurent d , Guy Pujolle c , Jean Philippe Wary e a Ericsson

Security Research, Montréal, Canada Ludwig-Maximilians-Universität, München Germany c Université Pierre et Marie Curie (UPMC), Paris, France d SAMOVAR, Télécom SudParis, CNRS, Université Paris-Saclay, EVRY, France e Orange Labs, Issy-les-Moulineaux, France b MNM-Team,

Abstract. The number of devices connected through the Internet of Things (IoT) will significantly grow in the next few years while security of their interconnections is going to be a major challenge. For many devices in IoT scenarios, the necessary resources to send and receive bytes are extremely high and when such devices are powered with battery the amount of exchanged bytes directly impacts their life time. As a result, compression of existing protocols is a widely accepted technique to make IoT benefit from the protocols developed over the last decades. This paper presents ESP Header Compression (EHC), a framework that enables compression of packets protected with Encapsulating Security Payload (ESP). EHC is composed of EHC Rules, targeting the compression of a specific field and organized according to EHC Strategies. Further, the paper presents Diet-ESP, an EHC Strategy that highly reduces the networking overhead of ESP packets to address the IoT security and bandwidth requirements. Diet-ESP results in sending fewer bytes which in turn reduces the number of required radio frames and thus battery consumption. The measurements showed that sending 10 byte application data on IEEE 802.15.4 radio networks secured with the standard ESP requires sending an additional frame. This results into a 95% energy overhead compared to the unprotected data, while Diet-ESP results only in a 3% overhead compared to unprotected data. This small overhead is achievable with some compressions being performed within the ESP stack which requires altering the same. Nevertheless, Diet-ESP remains fully security compliant to ESP and performs better than any other compression framework as far as ESP is considered. Keywords:, IoT, Security, IPsec, ESP, EHC, Diet-ESP, compression, performances

1. Introduction The public interest in IoT significantly grew in the last few years and the number of devices connected to the Internet is expected to grow significantly [47]. The exact expected number of devices to be connected in 2020 is subject to revisions. However, according to Bob Heile, chair of the IEEE 802.15, the trend of early previsions have proven to be true [46] and the trend remains to see IoT devices to top today’s 18.6 billion microcontrollers and 10.4 billion RFIDs. In its annual Mobility Report [11] Ericsson *

[email protected]

c 2017 – IOS Press and the authors. All rights reserved 0926-227X/17/$27.50

2

Migault, Guggemos, Killian et. al / Diet-ESP: IP Layer Security for IoT

estimates 28 billions IoT devices will be connected by 2021, while the expected number may be between 20.8 billions and 30.7 billion, respectively forecast by Gartner [20] and IHS Markit [39]. These devices are going to connect and influence almost any aspect of our daily life [22]. With a Compound Annual Growth Rate (CAGR) ranging from 18% [21] to 33.3% [58] from 2015 to 2023. The same reports expect IoT to impact multiple application domains such as Building and Home Automation, Smart Manufacturing, Smart Mobility And Transport, Connected Logistics, Connected Health, Smart Retail, Security and Emergencies, Smart Energy or Smart Environment. This interconnection, however, goes hand in hand with an increasing sense and skepticism about security and privacy issues by citizens [38,57]. All these paradigms have in common, that addressing the issues of security and privacy is going to become a major challenge for the industry, vendors and standardization organizations [7,74]. 1.1. Simple use cases under consideration Devices in many IoT scenarios can be classified according to their capabilities. For EHC Diet-ESP, we focus on scenarios with devices having energy limitations according to the classes E0 (Event energylimited), E1 (Period energy-limited) and E2 (Lifetime energy-limited) described in RFC 7228 [6]. Sensors of these classes are usually in an environment where external power sources are unavailable and battery replacements are impossible or rather expensive. As a result, these systems must be designed to limit the necessary resource while in operation. Sensor’s main operations are usually some specific tasks associated to a service as well as communication with other systems. Experts calculate the power consumption for wireless networking to be as expensive as 10-100 computing instructions. As mentioned in [61], one way to limit the necessary resource required by IoT communications over radio protocols such as SigFox [63], Lora [2], Bluetooth LE is the combination of current protocols with inexpensive compression. To put in a word, compressing the number of bits to be sent/received is seen as mandatory to address the increasing need of IoT communications while keeping the demand of resources low. Additionally, the increasing demand on IoT applications with permanent communications forms new paradigms of interest. This includes Fog Computing [5] for speeding up (IoT)applications by providing proximity data storage and computation, Dew Computing [65] supporting interconnection of devices in closed or isolated environments or Nano Data Centers [70] providing a representation of each device in the virtual network for more efficient interactions. These paradigms go hand in hand with an increased amount of networking, which is challenging for energy limited devices connected to such environments. The objective of this subsection is not to go further into details of these paradigms, but to illustrate possible usages of EHC Diet-ESP through four simplistic and abstract scenarios given in Figure 1, which illustrates typical communication models in these environments. As such, almost any scenario in IoT can be generalized into one of them. Figure 1a relates to a sensor simply sending data to a server where data like temperature, electrical consumption or health related measurements should be sent encrypted and authenticated in order to prevent information theft or any rogue device sending illegitimate information. Figure 1b introduces more flexibility with support of a bidirectional communication, thus providing the ability for the server to re-configure the node over time or to remotely actuating the node. Figure 1c illustrates a private network formed by a group of heterogeneous sensors communicating with each other over the public network and correlating their measurements. This communication model is for great relevance for the paradigms of Dew Computing and Nano Data Centres. The main difference to the use case in Figure 1b is the creation of VPNs to tunnel the communications.


(a) E2E unidirectional

(b) E2E bidirectional

(c) Private Cloud

(d) NFVI

3

Fig. 1. Use cases: IoT and security

Although the design of EHC is focused on energy limited devices, the potential use cases are not limited to scenarios with such constraints. Figure 1d illustrates the Network Function Virtualization (NFV) environment and more specifically to the virtualization of the home environment [12], where EHC can achieve improvements as well. An Internet Service Provider (ISP) deploys a virtual CPE1 (vCPE) inside its NFV Infrastructure (NFVI) to handle any complex operations (NAT, Firewall, QoS...), while the CPE is hosted in the home network and achieves minimal complexity. The only necessity is the establishment of a secure communication between the home network and the vCPE. For bandwidth saving, it is of interest for the ISPs to consider adopting specialized IoT security protocols for their access network. This communication model also applicates to the computing paradigm of Fog Computing. 1.2. Privacy and security issues in the era of IoT The privacy and security related issues in use cases associated to IoT are similar to the ones we already discovered during the last 10-15 years with the entrance of Personal Computers and Internet into our daily life [62]. However, IoT moves these challenges one step further by considering highly private and sensitive information as well as very constraint devices. Most of these “Things” are physically small and constrained in terms of computing power, memory, storage and energy which makes the use of current security protocols impracticable for a wide range of IoT scenarios. That is why standard protocols need to be redesigned to match each specific scenario while addressing the different constraints. In our case, this consists in moving a “one-fits-all-scenarios” protocol to a protocol instantiation tailored for each scenario. This is achieved by introducing the necessary flexibility to tailor a generic protocol differently for each scenario. 1.3. Motivation for IPsec and EHC compression Even though IPsec tends to be popular to secure infrastructures, applications tend to adopt TLS/DTLS. Remembering the use cases of IoT, these “Things” more naively fit into the term “infrastructures” rather than application. One reason for the preference of TLS/DTLS by application developers is IPsec being 1 Customer Premises Equipment: Equipment which is part of a public network but actually owned by the customer, e.g. private cloud devices.

4


implemented within the IP stack and thus usually implemented in the kernel. The lack of a standard control API makes it literally impossible for an application to query or configure IPsec on the host. Application developers prefer to link a static/dynamic and OS independent security library, making sure that their data is secured. With IoT, it is expected that applications are developed and optimized for a given device. As such, this user/kernel split is less of a problem. Our motivations for integrating IPsec, the IETF standard protocol to secure IP communications, into the IoT environment are as follows: First, IPsec secures any type of IP communications, including end-to-end, group and Virtual Private Network (VPN) communications. Second, IPsec has been designed as a suite of protocols which includes IKEv2 (Internet Key Exchange [33]) responsible for negotiating the cryptographic material and ESP which is used to encrypt the traffic. Having multiple protocols by design may be seen as complex compared to TLS (Transport Layer Security) [10] for example. However, such design provides more flexibility that is likely to fit multiple scenarios. For example, IoT may be using ESP with a control channel for the cryptographic material that differs from IKEv2. For some devices, lighter protocols may be needed such as DEX [44] or as described by 3GPP [40], where the cryptographic material is completely orchestrated by the operator. As a result the use of IPsec is very flexible for a variety of deployments. Third, IPsec has been a remarkably stable protocol over the last decades. While TLS has seen multiple versions - SSLv2, SSLv3, TL1.0, TLS1.1, TLS1.2 and TLS1.3 with different flavors for TCP and UDP (DTLS [56]), ESP has remained the same for more than 20 years, thus, guaranteeing a greater interoperability between devices with an expected life-time of ten years or more, which is very typical in many of the scenarios. In the case of IoT, the choice of TLS is likely to involve a long coexistence between the current TLS/DTLS version 1.2 and the next TLS1.3. Fourth, most of these devices are based on IEEE 802.15.4 which uses IKEv2 as a key management protocol for the negotiation of the cryptographic material of the radio layers. As a result, IKEv2, the natural control channel for IPsec, is likely to be already implemented in many devices, thus enabling IPsec to re-use already embedded code. Fifth, the kernel implementation of IPsec, which for web application is seen as a disadvantage, happens to be an advantage for IoT. Outsourcing security from the applications to the kernel through ESP is more likely to provide a more secure design. Moreover, except for IPsec, other VPN technologies like SSLVPN, PPTP or SSH are implemented in the user space and require heavy adaptation to a constrained environment. Flashing new firmware to the embedded device to apply a new VPN configuration and the need to handle virtual interfaces – such as tap or tun interfaces – to enable the VPN seems highly impracticable for such devices. However, building a VPN in IoT communications comes with the drawback of increased network overhead, which turns out to be a huge disadvantage in embedded devices where power is a limited resource and networking is very expensive. This disadvantage is fully addressed by EHC which completely removes the tunnel overhead. 1.4. Objectives and contributions of this paper This paper describes the ESP Header Compression (EHC) framework for the widely deployed IPsec ESP protocol [34] and an EHC compression strategy named Diet-ESP, that in conjunction of an EHC Context highly compresses the standard ESP overhead for IoT. Optimizations provided by EHC highly depend on the scenarios and refer to the principle of EHC to limit the size of the ESP packet to be


5

compressed by avoiding sending information and associated fields of the packet 1) that are negotiated by IPsec, 2) that can be derived from the packet or 3) that constitutes the ESP overhead. This paper considers bandwidth restricted scenarios, such as information exchanged about temperature, energy consumption, etc. The information itself is expected to remain encoded with a few bytes and be carried through a single radio frame. Radio frame size depends on the radio technology being used, 128 bytes for 802.15.4 [28], 59-230 bytes for LoRa [2], or 26 bytes for SigFox [63]. As a result the consideration of data range from 1 byte to 190 bytes seems relevant to our scenarios. The protocol design of EHC along with the Diet-ESP strategy is described in a set of IETF drafts [41, 23,42,24]. They used to be part of the 6lo Working Group (WG) [59], and has been recently moved to the ipsecme WG [69] as EHC requires some modifications of the ESP layer. In addition, significant interest has also been expressed outside the use case of IoT. The work performed at the IETF and in this paper are complementary. The IETF is focused on designing the EHC protocol, while the contribution of this paper are the following: A) ESP Header compression (EHC) framework: - 1 A comprehensible architecture description of the framework that enables the compression of ESP packets. The framework description includes design motivations as well as position regarding existing frameworks. - 2 A comprehensible and illustrated with examples description of the Diet-ESP EHC strategy, its associated EHC Rules and EHC context that define how ESP and the clear-text data can be compressed for IoT scenarios. - 3 The negotiation of the EHC context for Diet-ESP with IKEv2. - 4 The description of AES based algorithms that do not require sending the Initialization Vector (IV) in each packet, but use an implicit IV. B) A security analysis of Diet-ESP compared to standard ESP. C) An experimental platform of Diet-ESP based on sensors with the IoT OS Contiki. D) Experimental measurements of Diet-ESP on an IoT platform using IEEE 802.15.4 communications. 1.5. Organization of the paper The remaining of the paper is organized as follows. Section 2 outlines related work for secure communication with some specific approaches for the IoT. Section 3 describes the protocol design of EHC and how it is related to IPsec ESP. It also gives performance comparison between Diet-ESP approach and the other approaches given in the related work. Section 4 provides a security analysis of Diet-ESP. Section 5 explains the platform setup we used to evaluate Diet-ESP and section 6 discusses the measurements before section 7 concludes the paper.

2. Related Work Security for IoT should not be seen as a single protocol or a single module. In fact, security results at least in the combination of the following modules: authentication of the peers, key negotiation between the peers and session key derivation in order to finally secure the communications. For each module different protocols have already been designed and standardized. Some protocols or architectures are self contained and include all the modules, among them are TLS [10], DTLS [56], IPsec [33,34,35] or

6


HIP [45] with the derived HIP Diet Exchange [44] (HIP DEX). On the other hand, some protocols may be limited to specific modules like the authentication for PANA [15], EAP [1] and MIKey [3] for key management or ESP [34] for IP encryption. In order to secure IoT, one can choose the appropriate combination of each necessary module. The necessary modules can be taken from one or the other protocols. One may use a complete architecture like HIP, TLS or IPsec only for authentication. A complementary possibility is to modify existing protocols (or extend them) to address efficiently IoT. The design of EHC mostly consists in optimizing the module that secures communication by optimizing ESP. It also shows how EHC can be integrated in the IPsec architecture and especially how it can be used with IKEv2, the key management module of IPsec. That said, optimization of the control plane is out of scope of EHC. One reason is that we believe that the amount of data or processing related to control plane messages is low compared to those in the data plane. In addition, IKEv2 is considered as an example for control plane, but other control plane like HIP may be used as well. There have been several proposals to optimize the existing protocols for IoT needs. In the following, we describe the work which is mostly related to EHC. Table 1 summarizes the presented related work with their specific strengths and drawbacks. Heer et al. in [25] describe the security challenges of IoT and provide a functional comparison of the potential candidate protocols TLS/DTLS vs IPsec/HIP. Based on the challenges described in this study, Vidal Meca et al. [71] and Garcia-Morchon et al. [19] propose different security architectures based on HIP DEX. HIP DEX can be seen as a light alternative to IKEv2. Both protocols assume the communication uses ESP and thus EHC can be used instead as an optimized version of ESP. These works are complementary. Minimal IKEv2 [36] describes how the key exchanged can be optimized for constrained devices who would act as a client in an IKEv2 exchange. The optimizations focus on the fact, that embedded devices are usually configured to support exactly one desired cipher suite or one specific IPsec mode. With Minimal IKEv2, the IoT device sends exactly one proposal to the server which the server is expected to support. If it is not supported, the device will not continue to establish the connection. Minimal IKEv2 allows the control plane can be minimized, making EHC even more attractive for IoT use cases. Raza et al. in [49,51] investigate how IPsec may take advantage of the 6LoWPAN compression, that is to say AH and ESP. The ESP part may be directly compared to EHC but it can only compress the not encrypted ESP header with no modification of the ESP stack. Without modification of the ESP stack, this approach lacks the ability to compress the ESP payload, while EHC performs better compression than the one proposed by 6LoWPAN with the drawback of a modified ESP implementation. Although we believe the modifications are small enough, some manufacturers may prefer not to upgrade the ESP stack and instead extend the 6LoWPAN facilities. In that case, these pieces of work may be used instead of EHC providing a non optimized but acceptable compression for ESP. Similarly, the design difference between 6LoWPAN compression and Diet-ESP is the way of signalizing the compression. 6LoWPAN used the data plane, whereas EHC uses a control plane. Although the control plane is necessary to negotiate the IPsec parameters, some may prefer signaling compression parameters in the data plane. Nevertheless, Section 3.8 details how EHC interacts with 6LoWPAN. In [51], Raza et al. compare IEEE 802.15.4 linklayer security with a compressed 6LoWPAN/IPsec and show that IPsec is a feasible option for securing the IoT in terms of packet size, energy consumption, memory usage and processing time and that it scales better than IEEE 802.15.4. These results motivated our research on EHC.


7

ROHC defines mechanisms to compress/decompress the fields of an IP packet. Similar to 6LoWPAN, these compressors are placed between the MAC and IP layers. In the case of ESP, ROHC can be used to compress/decompress the ESP header. Because of its position in the protocol stack, ROHC cannot compress the already encrypted ESP payload. In some rare cases, when ROHC shares the IPsec cryptographic material, it may allow the compression of those fields, but these methods are strongly discouraged. ROHCoverIPsec was introduced as a method to compress the data before the packet is encrypted by IPsec. The current specification of ROHCoverIPsec considers the compression of the clear-text data, but none of the ESP related fields. Both protocols have been designed for bandwidth optimization, but not necessarily for constraint devices. As a result, the defined compressors are quite complex. They can also be dynamically activated during a session, based on the exchanged traffic. However, sensors are usually constrained in memory, while this complexity is usually too expensive for sensors and it is simply not feasible to deploy a full ROHC stack. Section 3.8 details the compression rate of EHC compared to ROHC, ROHCoverIPsec and 6LoWPAN ESP for various configurations. Vucinic et al. in [72], Kothmayr et al. in [37], Raza et al. in [53,54] and finally RFC 7925 [16] adopted and optimized the TLS-based approach to secure IoT communications. TLS/DTLS uses a single channel for signaling and data transfer. In other words, there are no separated control and data planes. These approaches include multiple optimizations for the initial exchanges [37], the compression of TLS/DTLS datagrams [53] and TLS/DTLS states [72]. Kothmayr et al. compared the network-energy overhead by comparing AES-128 CBC and a Raza’s compressed AES-128-GCM, showing the great interest of reducing the network overhead to limit the network energy overhead. Although TLS related architectures are almost orthogonal to EHC, their goals are similar. 3. ESP Header Compression Framework This section describes ESP Header Compression (EHC), the compression framework for ESP packets. Section 3.1 exposes why an IPsec based solutions fits the IoT needs and explains why security at OSI Layer 3 should be preferred over security provided by any upper layer. The structure and main features of ESP are described as a reminder in section 3.2. EHC is introduced in section 3.3. EHC is based on EHC Rules described in section 3.4, coordinated by an EHC Strategy. Section 3.5 describes our EHC Diet-ESP strategy experimentally tested in section 6. Section 3.6 shows how the encryption protocols used by ESP can be amended to further reduce the transmission payload. Section 3.7 details how DietESP contexts can be negotiated using IKEv2, the standard Internet Key Exchange protocol designed for IPsec. The advantages of EHC Diet-ESP are illustrated in 3.9 comparing an ESP secured IP payload with with related approaches and EHC Diet-ESP. EHC Diet-ESP compresses and decompresses according to an EHC Context agreed between the two peers. 3.1. Why IPsec? Diet-ESP is derived from IPsec ESP and inherits some of the IPsec’s advantages. Additionally to the advantages presented in section 1.3 IPsec makes security application-agnostic, as security applies directly on IP packets and does not care whether an application runs on top of UDP or TCP. This is obviously not the case for the current TLS [10] that protects only TCP communications and neither for its UDP counterpart DTLS [56]. However, this is expected to be addressed by the next version of TLS1.3 [55]. In addition, from a device perspective, IPsec can be seen as a firewall which centralizes the security. This

8

Migault, Guggemos, Killian et. al / Diet-ESP: IP Layer Security for IoT Table 1 Comparison of selected related works Proposed Solution HIP DEX

Major Optimization

Drawbacks

Applicable for IoT Yes

Compatible with EHC Yes

+ Optimized key exchange + Optimized ESP

– ESP network overhead – Requires ESP modification

Minimal IKEv2 (RFC 7815)

+ Optimized key exchange

– No data plane security – No compression

Yes

Yes

6LoWPAN ESP

+ Compression of ESP header

– No ESP payload compression – No VPN compressions

Yes

Yes

ROHC (RFC 5225)

+ Compression of ESP header + Compression of outer IP header

– Very complex – No ESP payload compression – No VPN compressions

No

Yes

ROHCoverIPsec (RFC 5856)

+ Compression of ESP payload (inner IP, TCP, UDP) + VPN support

– Very complex – Modified ESP stack

No

No

IoT DTLS (RFC 7925)

+ Optimized DTLS

– No IP layer security – Expensive VPN support – No compressions

Yes

Yes

EHC

+ Compression of ESP header + Compression of ESP payload (inner IP, TCP, UDP) + Optimized VPN support + Highly flexible compression

– Modified ESP stack

Yes

is more convenient and less error-prone than delegating the responsibility of the security policies to each individual application. Another advantage of IPsec is that IPsec is session free. Each packet is matched against a Security Policy Database (SPD) that points to the security material stored in a Security Association Database (SAD). This structure really fits the behavior of the considered class of nodes: rather than maintaining a session alive, a node may transmit data then fall asleep for an extended period of time and later still be able to communicate on the same secure channel until either party decides to expire the SPD or SA. IPsec has been thought naively with a tunnel and a transport mode. This fits naturally the E2E Communications and Private Cloud use cases, described in Section 1.1. For all these reasons, implementing security at the IP layer seems a desirable approach for IoT communications. 3.2. IPsec/ESP ESP [34] is one of the two security protocols of IPsec providing IP packets with confidentiality and integrity protection thanks to an IP option named as ESP payload, as represented in Figure 2. IPsec is defined to work in two modes, namely Transport and Tunnel mode. Transport mode is designed for endpoint-to-endpoint connections, whereas Tunnel mode is designed for connecting networks. That

9

Migault, Guggemos, Killian et. al / Diet-ESP: IP Layer Security for IoT 0

4

8

0

12

16

20

24

28

32

Security Parameter Index (SPI)

32

Sequence Number

64

Initialization Vector

96 128 160

Source Port

Destination Port

Length

Checksum

Encrypted Data

UDP Payload (variable) Authenticated Data

Padding Pad Length

NH=17 (UDP)

Integrity Check Value (ICV) Authentication Data

Fig. 2. packet structure for a ESP secured UDP packet in Transport Mode

is why, in Tunnel mode an additional IP-header is added on top of the ESP header and the original IP header is encrypted together with the application data. The construction of the packet to be transmitted requires the following chronological steps: 1. ESP Payload Alignment: Upon receipt of the unencrypted IP packet, compute the ESP Trailer so that the ESP Payload composed of data to be encrypted and the ESP Trailer meets 32 bits IP alignment. As depicted in Figure 2, the ESP Trailer is composed of three fields: Next Header (1 byte), the Pad Len (1 byte) and the Padding. Alignment consists in determining the Pad Length such that when the Padding field of Pad Length results in a 32 bit aligned packet. 2. chain appropriately the Next Header protocol: When used in transport mode, as represented in Figure 2, ESP can be seen as the insertion of a new header between the IP header and the transport header. This means that the next layer indicated by the IP header must indicate ESP while ESP needs to indicate that the transport protocol in its Next Header. Such indication will be used by the receiver to identify the encrypted packet as an ESP packet and to associate the decrypted packet with right transport protocol. When used in tunnel mode, the whole IP packet is encapsulated by ESP, in which case there is no insertion of a new header. Instead ESP defines a IP header followed by a ESP header that indicates the encrypted packet is an IP packet. 3. ESP Payload encryption: When the encryption is based on AES (AES-CBC, AES-CTR, AESCCM and AES-GCM), encryption and decryption requires an Initialization Vector (IV). This value is provided by appending the Encrypted Data to the IV to form the ESP Encrypted Payload as represented in Figure 2. 4. append the ESP Header: The ESP Header is composed of the Security Parameter Index (SPI) and the Sequence Number (SN) as represented in Figure 2. The SPI is used as an index by the receiver to identify the appropriated Security Association (SA). The SA contains among other parameters, the cryptographic material used for example to decrypt the ESP Encrypted Payload, or the current value of the Sequence Number. The SN is tested against the current Sequence Number stored in the SA in order to provide anti-replay mechanism.

10


5. Integrity Protection: the ESP Header and the ESP Encrypted Payload is integrity protected by a signature. With authenticated encryption algorithms such as AES-CCM or AES-GCM, the signature is generated together with the encryption. In some other cases, the signature requires a specific operation. The resulting Integrity Check Value (ICV) is appended to the ESP Encrypted Payload as depicted in Figure 2. Incoming packet procession occurs the reverse way, although the ESP Header has to be processed before the authentication can be checked. This is, because the SPI is the index to the cryptographic material and the SN is checked for preventing DoS attacks. 3.3. ESP Header Compression Overview ESP Header Compression (EHC) provides a framework as secure as ESP with a reduced networking overhead. The framework is composed of EHC Rules that define how fields in an ESP packet can be compressed and decompressed. Currently, EHC Rules concern any fields in ESP layer as well as the transport layer (UDP, UDP-Lite or TCP) and the IP layer if used in Tunnel Mode. These different EHC Rules are coordinated by an EHC Strategy and Diet-ESP is one of such strategies. The reason to define EHC Strategy is to avoid the peers to agree on a complex compression logic. Instead they agree on the EHC Strategy which is implemented in each of the peers. Besides agreeing on the EHC Strategy the peers need to provide via an EHC Context some additional parameters for the compression. In order to use EHC, we consider that while negotiating the SA, IKEv2 also agrees on the support EHC, the EHC Strategy and the EHC Context. Figure 3 illustrates the EHC Strategies and EHC Rules implemented by each peer. While negotiating the cryptographic material for example with IKEv2 as described in [41], both peers indicate the support of the Diet-ESP EHC Strategy and agree on the inputs for compression. Figure 3 also shows the ESP layer where the different EHC Rules occur. More details on these layers are provided in Section 3.4 NEGOTIATED: EHC Strategy

EHC Strategy

EHC Context

EHC Context

IMPLEMENTED:

IMPLEMENTED:

EHC Strategies

EHC Strategies EHC Rules

EHC Rules

ESP

ESP

pre-esp

pre-esp

clear-text esp

clear-text esp

encryption

encryption

post-esp

post-esp Fig. 3. EHC Overview


11

3.4. EHC Rules EHC Rules are expected to provide the smallest compression granularity. In most of the cases, EHC Rules are defined to compress and decompress a single field. For example, the EHC Rule ESP_SPI defines how to compress and decompress the SPI. In some cases, for example when different fields are not independent or when the fields are grouped into a same range of bytes, it is more natural for an EHC Rule to compress multiple fields. This is the case, for the EHC Rule ESP_PAD, which compresses the ESP Pad Length field and the Padding field. That is why an EHC Rule is designated by a name that does not specify a field. An EHC Rule defines all the fields the compression or decompression occurs to, the Action Function for compression or decompression as well as the necessary parameters to complete the compression or decompression. The possible defined Action Function are: - send-value: no compression or decompression is performed. - elided: the value is simply removed from the packet and retrieved from the local context. In some cases, the value may have been provided as input by the EHC Context or is retrieved from the IPsec databases. Such parameter includes the inner IP address used in the Tunnel mode. With the standard ESP, this value is stored both in the SAD as well as sent over the wire. - lsb: only the Least Significant Bytes (LSB) of the field are sent. Upon receiving them, the peer retrieves the Most Significant Bytes (MSB) from a local context. Such compression / decompression is typically used for SN. - lower: the field is omitted and then derived from the lower layers. Typical examples are length fields. - checksum: checksum is removed and re-computed. - padding: the ESP padding is omitted and re-computed when necessary. Motivations for padding may be 32-bit alignment or alignment to a cipher block size (such as with AES-CBC). In our case, AES-CCM does not have any block size and padding is only motivated by the alignment. The EHC Rules may be performed at various places in the kernel or in the protocol stack. For example, when the EHC Rule concerns the transport layer, such compression and decompression can be performed before the ESP encapsulation by the sender or after the ESP decapsulation by the receiver. This is represented in Figure 3 as the “pre-esp” layer. Similarly the EHC Rules associated to the SPI or SN can be performed after the ESP encapsulation by the sender and before the ESP decapsulation by the receiver. Such layer is represented by the “post-esp” layer in Figure 3. In both cases, these EHC Rules would not require any modification of the ESP protocol and the ESP implementation would not require any modifications. On the other hand, when the EHC Rule applies on the “clear text esp” layer, that is any ESP field before the encryption occurs, the EHC Rule must be implemented in the ESP stack and the ESP implementation needs to be updated. 3.4.1. Diet-ESP EHC Rules This section details the EHC Rules associated to the Diet-ESP EHC strategy by showing the most important rules for ESP, IPv6 (in Tunnel Mode) and UDP (see Table 2). These are the protocols which are of major interest for IoT use cases. Note that these represent only a subset of the Diet-ESP EHC Rules and there are also rules available for IPv4, UDP-Lite and TCP. These EHC Rules have not been mentioned as these protocols are less important for IoT and we wanted to keep the paper short. However, Section 3.5 provides a high level view of these additional compressions while detailing the EHC Strategy.

12

Migault, Guggemos, Killian et. al / Diet-ESP: IP Layer Security for IoT Table 2 EHC Rules for ESP, IPv6 and UDP EHC Rule

Field

ESP_SPI ESP_SN ESP_NH ESP_PAD ESP_ICV IP6_OUTER IP6_VALUE IP6_LENGTH IP6_NH IP6_HL_OUTER IP6_HL_VALUE IP6_SRC IP6_DST UDP_SRC UDP_DST UDP_LENGTH UDP_CHECK

Security Parameter Index Sequence Number Next Header Pad Length, Padding ICV Version, Traffic Class, Flow Label Version, Traffic Class, Flow Label Payload Length Next Header Hop Limit Hop Limit Source Address Destination Address Source Port Dest. Port Length UDP Checksum

Action Function lsb lsb elided padding lsb elided elided lower elided lower elided elided elided elided elided lower checksum

Negotiated Parameter SPI_LSB SN_LSB, SN_GEN ALIGN ICV_LSB IP6_TC, IP6_FL

SA Parameter esp_spi esp_sn l4_proto, ipsec_mode esp_encr ip_version ip_version l4_protocol

IP6_HL ip6_source ip6_dest l4_source l4_dest

As shown in Table 2, some protocol fields (e.g. Hop Limit of IPv6) can be compressed with different Action Functions. Obviously, one of these functions needs to be chosen when setting up the context and a context using two or more Action Functions for one field must be rejected. On the other hand, this achieves a high level flexibility. In a scenario where Tunnel mode is used it might be acceptable to simply copy the Hop Limit from the outer IP header to the Tunnel IP header. In other scenarios, one may want to set a pre-defined Hop Limit to the Tunnel IP header, once the packet is decapsulated. Both options are possible with Diet-ESP. The parameters mentioned in capital letters are the parameters agreed between the security endpoints before the ESP connection starts. Such parameters are expected to be agreed during the IKEv2 exchange. In other words, theses values must be explicitly provided via a specific IKEv2 extension. The other parameters in small letters are already agreed with the standard IKEv2 exchange. The rules together with the additional parameters form the Diet-ESP EHC Context. Even in the worst case, compressing ESP, IPv6 and UDP with Diet-ESP requires only eight additional parameters to be exchanged. In the best case – when Version, Traffic Class, Flow Label and Hop Limit are read from the outer IP packet –, Diet-ESP only requires six additional parameters. All other parameters are exchanged via IKEv2 by default and already part of the Security Association. Of course, applying the corresponding rules require the values in the SA to be non-wildcard values. ESP_ICV has not been specified in [42] and has been kept for experimentation. It results from the dilemma between the IoT need to tailor protocols according to specific deployment versus the need to standardize general purpose security. The main reason for not having it in the standard is, that the length of the signature is a property of the algorithm and ESP should not be able to change those properties. In particular, when using AESCCM as recommended in [43] the strength of the signature linearly depends on length of the signature,


13

this is typically not the case when AES-GCM is used [13,31]. As a result, the length of the signature should be defined by defining appropriate cryptographic suites. However, cryptographic suites are mostly standardized for general purpose, in which case standardizing a cypher-suite with weak signature is unlikely to happen. As mentioned by Ferguson: “A general-purpose cipher mode should adapt to the widely different circumstances in which ciphers are used. From an engineering perspective, a mode that has acceptable behavior for almost all situations is preferable to a mode that is very good in some situations and very bad in others.” [13] On the other hand, with the considered class of devices there is a need to be able to compress any protocol according to its specific needs. This principle applies also for cryptography and so contradicts the general-purpose nature of a standardized cryptographic suites. In our case, the reason for having a weak signature is as follows: In some case compromising a reasonable number of packet does not compromise the overall result. Suppose a server collecting data from hundreds of sensors that all provide the instance of a measurement like a temperature. The server is likely to derive the temperature by taking the median of the measurements or by doing any sort of operations to clean the data. In this specific case, compromising the overall measurement requires to compromise a large number of instances. As a result, there might be a compromise between enabling weaker signature versus the number of measurements. Of course such considerations must be carefully balanced and understood. It is also likely that some architects will under-estimate the security versus the overall bandwidth performance and will design a weak system which is the reason that the EHC Rule “ESP_ICV” is not part of the standardization of EHC. 3.5. EHC Strategy: Diet-ESP IoT was the primary use case for compressing ESP, thus resulting in the EHC Strategy: Diet-ESP. However, Diet-ESP also raised a significant interest for non IoT communication. As a result, Diet-ESP has been designed for maximizing compression for IoT communications as well as providing significant compression for more standard communications, that is mostly VPN carrying TCP traffic. IoT devices are mostly dedicated to a single application. As a result, one can reasonably expect that IoT communications are between the device and a server. In other words, the communication is between two IP addresses: IPdevice and IPserver . In addition, the IP communication in IoT is likely to use no transport protocol or UDP as a transport protocol, in which case the source and destination ports may be fixed. All these parameters constitute the Traffic Selectors negotiated by IKEv2. On the other hand, the traditional VPN is likely to secure any communication initiated by the device and does not have any fixed server destination. In addition, with HTTP as the de-facto standard for traditional traffic, TCP is likely to be used without specific ports as Traffic Selectors. TCP can be compressed decently, but Diet-ESP balances the overall advantage of bandwidth compression of TCP versus the additional computation and the current trend is not to compress TCP except the ports. The Diet ESP EHC Strategy for outbound packet can be summed up as below: 1. pre-esp: check the Traffic Selector matches an ESP Security Policy that enables Diet-ESP. 2. pre-esp: if the transport protocol (TCP, UDP, UDP-Lite) as well as source and destination ports are part of the Traffic Selectors, then compress the agreed port fields, the checksums as well as the length field. In the case of TCP, other fields are defined in the EHC Context. In any other case, do not compress the transport layer. Note that Diet-ESP only requires parameters when TCP needs to be compressed.

14


3. clear-text: compress Padding, Pad Length and Next Header as detailed in Section 3.4.1. By default Diet-ESP provides all necessary parameters to compress the ESP packet before the encryption occurs. In addition, if the SA uses the Tunnel Mode and the inner IP addresses are specified in the Traffic Selectors, than compress the inner IP header. 4. encryption encrypt the ESP payload, generate and add the ICV. 5. post-esp: proceed to the compression of the SPI and Sequence Number as described in Section 3.4.1. For inbound packet, Diet-ESP works as follows: 1. upon receiving a packet check the compressed SPI index an SA. Note that this step may be eased when the server uses a single lsb of SPIs. Otherwise multiple checks may be performed. 2. post-esp: decompress the SPI and SN 3. encryption: check the signature (ICV) and decrypt the ESP packet. 4. clear-text: decompress the ESP fields. If the mode for ESP is set to Tunnel, then decompress the inner IP addresses. 5. pre-esp: decompress the transport layer when compressed. 3.6. Further compression with new encryption protocols A Diet-ESP Context defines how ESP and transport related fields are compressed. Diet-ESP offers an additional method to remove a few more bytes from the ESP packets secured by AES. As depicted in Figure 2, with the currently defined AES encrypted payloads, an IV is provided in each packet and is required for decryption. The IV’s of AES-CBC and AES-CCM/AES-GCM have different characteristics. With AES-CBC, the IV must be non-predictable, whereas with AES-CCM/AES-GCM the IV must not repeat. In order to satisfy the various IV properties, [24] defines new protocol suites that specify how the IV can be generated by each peer rather than transmitted along the data. With AES-CTR, AES-CCM and AES-GCM, the only requirement on the IV is that the 8 byte IV must not repeat for one key. As a result, the Sequence Number (SN) of the IPsec packet can be reused in order to generate the IV. When the Extended Sequence Number (ESN) is activated, the SN is 8 bytes long which matches the IV. When the ESN is not used, then the SN is 4 bytes long, the remaining bytes are set to zero to have a 8 byte IV. Note that when the SN is compressed, the SN is not read from the packet. For AES-CBC the IV is built the same way by using the SN and ESN if available. In contrast to the Counter Modes, AES-CBC requires the IV to be unpredictable, which cannot be ensured by using the SN exclusively. That is why, the resulted IV is encrypted with AES-CBC which produces a 16 byte unpredictable IV. The key is derived by the same function used to derive the keys for encryption. In case of IKEv2 this function is called “KEYMAT” and ensures secure keys on both sides of the communication. 3.7. Diet-ESP Extension for IKEv2 IKEv2 is the Internet Key Exchange protocol used by two peers to negotiate the different parameters of a SA such as the Traffic Selectors, the mode as well as the cryptographic material associated to a SA. Basically the initiator sends some proposals to the responder which chooses one of the proposal. IKEv2 has been designed as quite modular, so that it can be extended in order to agree additional parameters. The negotiation of the IKEv2 extensions are usually composed of the following phases: announce of the support followed by an agreement to use the extension with eventually its associated parameters.

Migault, Guggemos, Killian et. al / Diet-ESP: IP Layer Security for IoT HDR

IKE_SA_INIT Request

IKE_SA_INIT Response HDR, SAr1, KEr, Nr IKE_AUTH Request HDR, SK, {IDi, AUTH, SAi2, TSi, TSr, N(DIET_ESP_PROPOSALS) } IKE_AUTH Response HDR, SK, { IDr, AUTH, SAr2, TSi, TSr, N(DIET_ESP_PROPOSAL) }

R E S P O N D E R

PHASE 2

I N I T I A T O R

PHASE 1

HDR, SAi1, KEi, Ni

SAi1, SAr1 KEi, KEr

= IKEv2 Header =

Offered and chosen algorithm Diffie-Hellman group

= Diffie-Helman values

Ni, Nr

= Nonces

IDi, IDr

= Identity

SK{…}

Indicates payloads are = encrypted and integrity protected

AUTH

Authentication: = Pre-shared secrets + IDs or Digital Certificates

SAi2, SAr2 TSi, TSr N

15

=

Algorithm Parameters for IPsec_SA

= Traffic Selector for IPsec_SA = Notify Payload

Fig. 4. Diet-ESP context negotiation with IKEv2

The use of IKEv2 is not mandatory to agree on SA. In fact SA may be negotiated using other protocols such as HIP or DEX or may be manually configured. In 3GPP for example, SA are managed by the operator and not by the peers. This section details how IKEv2 can be extended in order to negotiate the support and the use of EHC as well as the EHC Strategy Diet-ESP and its associated EHC Context. The principle applied to IKEv2 for the EHC element agreement can be applied in a similar way with other key management protocols. When manual configuration is used, of course these EHC values need to be manually configured as well. IKEv2 has not been subject to compression. IKEv2 exchanges are not expected to occur often. Thus, a compression for IKEv2 is left for future work. This section also discusses how to limit the size of the IKEv2 payload by choosing appropriate algorithms for the Diffie-Hellman and for the authentication. When an initiator wants to negotiate a Security Association (SA) using Diet-ESP, it negotiates a regular SA with a SA Payload and indicates its willingness to establish a Diet-ESP session. In order to set the Diet-ESP session, a Diet-ESP Context must be agreed between the two peers. To indicate its preference for Diet-ESP instead of standard ESP, the initiator adds a DIET_ESP_PROPOSAL Notify Payload. This Notify Payload carries a Diet-ESP Proposal Payload which can be seen as a container proposing Diet-ESP Contexts Payload. The Diet-ESP Proposal Payload indicates the DietESP Context ID, a Diet-ESP Context Payload Format. These parameters enable to derive properly the Diet-ESP Context parameters from the Diet-ESP Context Payload. Figure 4 illustrates the case where the initiator and the responder agree on a Diet-ESP Context. The negotiation occurs during the IKE_AUTH exchange. However, the negotiation can occur for any Child SA negotiation. In order to meet security standards by 2030, NIST [4] recommends that factoring modulus and discrete logarithm group be greater than 3072 bits and that elliptic curve keys be greater than 256 bits. In order to limit the size of the transmitted payloads, there is an advantage in using elliptic curves. As a result, the recommended configuration for IKEv2 [27] with IoT is to use 256-bit random ECP group [60] (number 19) for the Diffie-Hellman exchange and ECDSA with SHA-256 on the P-256 curve [18] for the IKEv2 authentication.

16


3.8. Compatibility with other Compression Framework As mentioned in Section 1.2, compression became very important for IoT, so compatibility between different frameworks and protocols should be ensured wherever possible. 6LoWPAN and ROHC are used to compress/decompress the IP header together with upper layer protocols, such as UDP and TCP. 6LoWPAN is the protocol, which enables IPv6 in the constrained environment of the considered IoT scenarios and thus it is widely implemented. Thus making EHC and Diet-ESP compatible with 6LoWPAN was a major goal while designing the protocol. However, 6LoWPAN and ROHC are both located between Layer 2 and Layer 3, while the mechanism for making EHC compatible is the same for both protocols. Without encryption, 6LoWPAN compresses the IP and UDP header. At the moment of writing, ESP is not part of the 6LoWPAN specification, although Raza et al. [52] showed, how ESP could be integrated into 6LoWPAN. Without changing the IPsec implementation, 6LoWPAN is only able to compress the part of ESP which is send in plain text, such as the SPI and the Sequence Number. This assumption is also true for ROHC, however ROHCoverIPsec specifies how the IPsec stack needs to be changed to enable compression of the encrypted payload. As EHC and Diet-ESP only compress ESP related fields and the encrypted ESP payload, the overlap between the protocols are only the SPI and the SN. In order to use ESP compressions in 6LoWPAN, the peers simply need to negotiate the SPI and Sequence Number to be not compressed by EHC with the Diet-ESP context. This could even be automatically observed. Technically, this means SPI_LSB and SN_LSB have to be negotiated with the value 4. On the other hand, the benefits of this separation are worth mentioning. By using the information IPsec provides, Diet-ESP can accomplish much higher compression as any other current protocol even if it is implemented within the IPsec stack, like ROHCoverIPsec or its 6LoWPAN – only theoretical available – counterpart. Due to their implementation within the IPsec stack they would directly interfere with Diet-ESP while a compatibility with these two extensions is not useful and thus not considered. However, to the best of our knowledge, there are currently no actions of implementing 6LoWPAN for ESP encrypted payloads, while Diet-ESP remains the only compression framework suitable for encrypted communications in constrained environments. The Contiki operating system supports 6LoWPAN, while our implementation and test setup (see Section 5) can be configured to use 6LoWPAN and proves that the previous assumption is valid. 3.9. Performance comparison for 1 byte application data This section considers the E2E Unidirectional use case as described in section 1.1. The sensor at one end needs to send 1 byte of payload to its counterpart every minute and would like to send the data using UDP, in a secured fashion. For this comparison, the Transport mode of ESP is used, but the same results are comparable to Tunnel mode. The table in Figure 5 sums up the savings for the different IPsec modes. In the ESP scenario, the two hosts follow the standard encryption and encapsulation method as briefly recapped in section 3.2. The secrets for the encryption are built during the negotiation phase using the IKEv2 control plane of IPsec. In this section we assume the node using AES-CCM with a 8 byte IV and a 12 byte ICV. The resulting ESP packet is thus built as follows: The ESP Header is composed of the 4 byte SPI and the 4 byte SN, followed by the 8 byte AES Initialization Vector (AES IV). The IP payload is composed of the 8 byte UDP header and the 1 byte application data. In order to respect the IPv4 32 bit alignment, the ESP trailer is composed of 1 byte of padding followed by 1 byte for the Pad Length and 1


17

byte for the NH field. The remaining 12 bytes are those of the ICV. Note that the following example also provides a 64 bit alignment required by IPv6. For EHC, the two hosts additionally agree to use the Diet-ESP profile with the following EHC Rules and EHC Context. The peers further agree to use an encryption protocol with Implicit IV. EHC Rule Name ESP_SPI ESP_SPI ESP_SN ESP_NH ESP_PAD ESP_ICV UDP_SRC UDP_DST UDP_LENGTH UDP_CHECK

Action Function lsb lsb lsb elided padding lsb elided elided lower checksum

EHC Context Parameter SPI_LSB=4 SPI_LSB=4 SN_LSB=4, SN_GEN=“incremental” ALIGN=“1 byte” ICV_LSB=12

Figure 5 compares the final packet protected with ESP in Transport mode and compressed with EHC Diet-ESP, 6LoWPAN, ROHC, ROHCoverIPsec. With ESP Tunnel mode, the amount of transferred bytes would be the same for Diet-ESP and ROHCoverIPsec, but would result in an additional IP header in all other cases. 6LoWPAN can reduce the ESP header by 4 bytes but cannot compress the encrypted ESP payload. ROHC is able to fully compress the ESP header and ROHCoverIPsec the UDP header respectively resulting in a 8 byte reduction each. Combining them would lead to a total reduction of 16 bytes. With the outlined configuration, EHC Diet-ESP can, however, completely compress the ESP header, AES IV, UDP header and the ESP trailer. The table in figure 5 shows, that even in “worst case” of Transport mode, EHC Diet-ESP results in a 27 bytes reduced networking overhead (67%) compared to regular ESP. Due to its complexity ROHC is not applicable to IoT, but EHC Diet-ESP still beats it by 11 bytes (45%). 6LoWPAN would be applicable for IoT, but with its current standardization, does not improve ESP at all and EHC Diet-ESP beats it by 23 bytes (63%). In Tunnel mode, EHC Diet-ESP unrolls its power. The potential savings are 67 bytes (83%) compared to ESP and 63 bytes (82%) compared to 6LoWPAN for IPv6. Although not useful for IoT and thus only theoretical, the savings for IPv4 tunnels are similarly impressive. There is room for further reduction by compressing the ICV, but the security could be compromised. One may argue that securing a one byte encrypted payload is neither confidential nor authentic. However, most of the fields shown in Figure 5 are either not encrypted, very easy to guess (e.g UDP length) or easy to brute-force (e.g. UDP ports or Tunnel IP addresses) why an attacker would have an easy job to find out the clear-test values, even without compression (see also section 4). Additionally, the authentication in IPsec is done via HMAC and guessing a correct ICV would still be difficult without having the right key.

4. Security Analysis This section describes how the compression of the attributes in with EHC impacts the security over the non compressed attributes of ESP. EHC does not introduce weak security as it uses a deterministic decompression. This means that compression / decompression only introduce a limited and upper-bound overhead. As illustrated in Figure 2 an ESP packet can be considered as a Security Parameter Index (SPI), followed by the Sequence Number (SN) followed by the Encrypted Payload.

18

Migault, Guggemos, Killian et. al / Diet-ESP: IP Layer Security for IoT 16

Data

Transport

IPv6 Tunnel

IPv4 Tunnel

UDP-Header

UDP-Header

ESP-Header

AES IV

Data

AES IV

AES IV

IPsec Mode

UDP-Header

AES IV

ESP-Trailer

Diet-ESP ICV (variable)

32

40

ESP-Trailer

ESP-Trailer

ICV

ESP 40 Bytes

ICV

6LoWPAN 36 Bytes

Data

ESP-Header

AES IV

Data

ESP-Header

24

Data

8

ESP-Trailer

ICV

ROHC 32 Bytes

Data

0

ESP-Trailer

ICV

ROHCoverIPsec 32 Bytes

ICV

ROHC+ROHCoverIPsec 24 Bytes

Diet-ESP 13 Bytes

Protocol ESP 6LoWPAN ROHC ROHCoverIPsec ROHC + ROHCoverIPsec EHC Diet-ESP ESP 6LoWPAN ROHC ROHCoverIPsec ROHC + ROHCoverIPsec EHC Diet-ESP ESP 6LoWPAN ROHC ROHCoverIPsec ROHC + ROHCoverIPsec EHC Diet-ESP

ESP SPI

ESP SN

AES IV

4 2 0 4 0 0 4 2 0 4 0 0 4 2 0 4 0 0

4 2 0 4 0 0 4 2 0 4 0 0 4 2 0 4 0 0

8 8 8 8 8 0 8 8 8 8 8 0 8 8 8 8 8 0

Tunnel IP

UDP

Data

8 8 8 0 0 0 8 8 8 0 0 0 8 8 8 0 0 0

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

40 40 40 0 0 0 20 20 20 0 0 0

ESP Trailer 3 3 3 3 3 0 3 3 3 3 3 0 3 3 3 3 3 0

ICV

Σ

12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12

40 36 32 32 24 13 80 76 72 32 24 13 60 56 52 32 24 13

Fig. 5. Diet-ESP vs ESP for a 1 byte clear-text data

The Security Parameter Index (SPI) is used by the receiver to index the Security Association that contains appropriated cryptographic material. If the SPI is not found, the packet is rejected as no further checks can be performed. In EHC, the value of the SPI is not reduced, but compressed while the SPI value may not be fully provided between the compressor and the decompressor. On the other hand, its uncompressed value is provided to the ESP-procession and no weakness is introduced to ESP itself. On an implementation perspective, compression and decompression adds some additional treatment to the ESP packet, which might be used by an attacker. In order to minimize the load associated to decompression, decompression is expected to be deterministic. The incoming compressed SPI with the associated IP addresses should output a single and unique uncompressed SPI value. If n uncompressed SPI values have to be considered, then the receiver could end in n signature checks which may be used by an attacker for a DoS attack. On a privacy perspective, until EHC Diet-ESP is not deployed outside the scope of IoT and small devices, the use of a compressed SPI may provide an indication that one of the endpoint is a sensor. Such information may be used, for example, to evaluate the number of appliances deployed, or – in addition with other information, such as the time interval, the geographic location – be used to derive the type of data transmitted.


19

The Sequence Number (SN) is used as an anti-replay attack mechanism. With the mechanism of Extended Sequence Number (ESN), compression and decompression of the SN is already part of the standard ESP. EHC Diet-ESP enables to reduce the SN of 32 bit long to 0 bytes and the main limitation to the compression is a deterministic decompression. SN compression consists in indicating the least significant bytes of the uncompressed SN on the wire. The size of the compressed SN must consider ro the maximum reordering index such that the probability that packet pn−r , r > ro arrives before packet pn . In addition the size of SN should also consider maximum consecutive lost index lo such that the probability that l, l > lo consecutive packets lost during transmission is minimized. Suppose SN is incremented by one for each packet, the field for the compressed SN must be able to store max(ro , lo ) distinct values. In case that the SN is generated through a function f , the fields associated to SN must be able to store max(|f |ro , |f |lo ), with |f |xo = max(f (x) − f (x − xo ), x ∈ [xo , ∞]) values. In the case of ESP, ro is set to 232 which is largely over-provisioned in most real world case. In other words, the size of the compressed SN has to be large enough to cover the worst case of packet loss / reordering. If the compression of the SN is not appropriately provisioned, the most significant byte value may be not synchronized between the sending and receiving parties. Although IKEv2 provides some re-synchronization mechanisms [64], in case of IoT the lose of synchronization will most likely result in a renegotiation and thus DoS possibilities. Note that IoT communication may also use some external parameters, i.e. other than the compressed SN, to define whether a packet be considered or not and eventually derive the SN. One such scenario may be the use of time windows. Suppose a device is expected to send some information every hour or every week. In this case, the SN may be compressed to zero bytes. Instead the SN may be derived by incrementing the SN every hour after the last received valid packet. Using the time the packet is received as SN enables considering the time derivation of the sensor clock. Note also that the antireplay mechanism needs to define the size of the anti-replay window. RFC 4303 [34] provides guidance to set the window size and are similar to those used to define the size of the compressed SN. The size of the compressed SN has to be larger than the window size, otherwise compression enables replay-attacks. In a privacy perspective, if incremented for each ESP packet the SN may leak some information like the amount of transmitted data or the age of the sensor. The age of the sensor may be correlated with the software used and the potential bugs. On the other hand, re-keying will re-initialize the SN, but the cost of a re-keying may not be negligible and thus, frequent re-keying can be considered as impracticable. In addition to the re-key operation, the SN may be generated in order to reduce the accuracy of the information leaked. In fact, the SN does not have to be incremented by one for each packet but has to be an increasing function. Using a function such as a clock may prevent characterizing the age or the use of the sensor. Note that the use of such function may also impact the compression efficiency and result in larger SN to be send on the wire. Padding, Pad Length and Next Header are fields stored inside the encrypted payload. They are part of the ESP payload so that ESP can be seen as an IP option. IP extension headers must have 32 bit ByteAlignment in IPv4 [48] and 64 bit Byte-Alignment in IPv6 [9]. The main motivation for the alignment is the improvement of packet processing on 32 or 64 bit processors. As a result, compression of these static fields does not impact the security of EHC Diet-ESP compared to the one provided by ESP. EHC Diet-ESP defines the removal of the Initialization Vector from the encrypted packet not as a compression performed by EHC itself. The removal of the IV from the standard ESP payload results in the definition of a cryptographic suite, which is independent from ESP. In this document we showed a set of implicit-iv-cipher-suites with new IANA codes. The IV has different properties depending on the cipher suite, e.g. for AES-CTR, AES-CCM or AES-GCM it is not allowed to be repeated for one encryption key. As a result, the new cipher suite defines a way to generate the IV based on the SN or

20


ESN to generate a not repeated IV. The non implicit counter part can generate their IV the same way and re-include it in the ESP payload. Note that removing the IV from the packet is proven to be uncritical for security matters, e.g. TLS1.3 does not specify the IV to be part of the payload either. Similarly EHC Diet-ESP provides a way to truncate the size of the Integrity Check Value. This is not a compression mechanism as the ICV is not decompressed. The main motivation of adding this mechanism was to provide a mechanism to adapt the size of the ICV without creating a new cipher suite. This resulted by considering the specialty of IoT scenarios in constrained environments and the need for some tools to shape the security according to the scenario. With that mechanism, EHC Diet-ESP is able to provide a short ICV for which no cipher suite have been defined, yet. EHC seems to be the right place to do so as cipher suites are standardized for general purpose use and are expected to be used in multiple situation were data has to be encrypted and authenticated. Similar to the SN the ICV sometimes seems to be over-provisioned with regards to the expected security and accepted risk. The inclusion of this mechanism keeps the IANA define cryptographic suite for general purpose while EHC provides tools to shape the cryptographic suite to very specific cases. Suppose a scenario where a sensor uses AES-XCBC with authentication in a 4 byte ICV. Such authentication cannot be of general purpose but still fit specific scenarios, e.g. if a sensor provides data used for statistical treatments. In such specific scenarios, even one value being spoofed may not impact the overall result. In addition, as the sensor is expected to send data with a very specific pattern, such an attack would generate some traffic that might be noticed. Similarly, Ferguson [13] provides examples where the risk associated to a weak authentication are acceptable. If a packet within a voice audio conversation is spoofed, the conversation is not impacted and the attack is likely to be detected as the voice channel may remain silent because of bad packets. On the other hand, the security associated to the ICV depends on the used cryptographic suite. A 4 byte ICV does not provide the same level of security whether being used with AES-GCM or with AESXCBC. This is because GCM requires strong authentication in order to keep the encryption secure. For this reason, the specification of the ICV may be better defined with the cryptographic suite rather than ESP. As suggested by Fluhrer [14], the consideration of a short ICV should be restricted to ICV based on HMAC or CMAC only. Ferguson [13] exposed weakness of using GCM with short tags and Mattsson et al. [31] provides an analysis of the use of GCM with IPsec. 5. Experimental setup EHC was designed with three major requirements in mind: keep the security of ESP with no concessions, keep implementation complexity low and minimize the network-energy overhead on battery to limit the impact of security on the lifetime of constrained devices. The security of EHC was explained in section 4 and is thus not to be tested in this experimental study. However, the complexity of the protocol was verified by implementing the compression on top of an existing ESP stack, in a famous OS for embedded devices. Lastly, the protocol was evaluated against the requirement of battery-friendliness, by testing the code on a network of sensors and measuring the impact on the lifetime of the tested devices. This section presents the platform that was used for the evaluation The test platform is presented in Section 5.1. The choice of a software base is discussed in Section 5.2 and lastly, the parameters and the environmental choices for the testing are given in Section 5.3. 5.1. INRIA’s FIT IoT-LAB as the test platform INRIA’s FIT IoT-LAB (or simply IoT-LAB) has been selected as the hosting platform to run the testing as the platform is hosting multiple kind of devices. This provides the opportunity for us to avoid being

21


locked into a single technology especially if our development could not fit the target devices. In addition, the platform proposed M3 sensors which seems to us a good target. Finally the INRIA’s team is pretty active at the IETF and very responsive. An extract from the IoT-LAB website gives a fair description of the platform [29]: “[...] IoT-LAB features over 2700 wireless sensor nodes spread across six different sites in France. [...] A variety of wireless sensors are available, with different processor architectures (MSP430, STM32 and Cortex-A8) and different wireless chips (802.15.4 PHY @ 800 M Hz or 2.4 GHz). [...]” IoT-LAB provides a documented and open platform with high availability to the community of developers. This makes the evaluation that is exposed in this document reproducible and helps promote the testing by external peers and contributors. Openness aside, the nodes of IoT-LAB have key features for this study: The hardware supports a sleep mode, which turns out to to be the standard method to achieve extended lifetime, during which only very limited functions run, such as a low precision timer. Additionally, the radio link uses the IoT standard IEEE 802.15.4. Lastly, as shown in Section 5.3, capturing the electrical characteristics (current intensity and voltage) is easy to achieve. IoT-LAB supplies three types of nodes. The M3 sensors [30] were selected, as they provide the best compromise between ROM space (big enough to host Contiki and the ESP stack) and electrical budget (small enough as to put emphasis on the power used by the radio and the packet preparation). Table 4: Profiles under test

Table 3: Consumption of main parts on the M3 sensor compression

part stm32f103 (cpu) at86rf231 (radio) N25Q128A13 (flash) lsm303dlhc (accelerometer)

ESP

EHC DietESP(p)

EHC DietESP(f)

sleep mode

max

(mA)

(mA)

SPI size

-

4 bytes

0 byte

0 bytes

33 @72M hz

SN size

-

4 bytes

0 byte

0 bytes

NH

-

1 byte

0 byte

0 byte

PAD

-

1 byte

0 byte

0 byte

9 0.00002

14 @+3dBm

0.1

15

0.001

0.110

ALIGN

-

4 bytes

1 byte

1 byte

8 bytes

8 bytes

0 byte

0 byte

integrity algorithm

-

AESXCBC

AESXCBC

AESXCBC

ICV size

-

12 bytes

12 bytes

1 byte

encryption algorithm

-

AESCTR

AESCTR*

AESCTR*

IV

-

8 bytes

0 byte

0 byte

UDP header

isl29020 (light sensor)

0.0005

0.065

lps331ap (pressure sensor)

0.0005

0.030

0.005

6.1

l3g4200d (gyroscope)

Unprotected

Considering the electrical consumption of the main parts of the M3 nodes, summarized in Table 3, the average instant power of a node is estimated at about 20mW during sleep mode and 70mW during emission of radio frames. The sleep budget is quite high on this platform. To achieve long lasting operational life (typically 10 years), IoT nodes equipped with today’s batteries, should run on an average budget of 10µW . As shown in Section 6, this will give us some uncertainty on the measure of the lifetime of a node using EHC. Each sensor is associated to a ’control node’: a small appliance that controls the power source of the sensor, monitors its electrical characteristics, captures it’s serial output and runs various management

22


tasks (e.g. firmware updates). For example, Figure 7 shows the instant power measured on a sensor running a loop of 3 actions: 1)idle time, 2)preparation of data and 3)transmission on the radio link. Peaks at 70mW correspond to the activity of the radio (transmission). There is no measurable difference between the power during idle time and power during the preparation phase of the data. The smaller peaks correspond to the radio being switched on and off for a very short time by the OS. The number of those peaks correspond to the chosen radio duty cycle (RDC), in this case 8 cycles per second (more on this in Section 5.2). 5.2. Contiki OS as the basic software Up to now, IPsec is not widely spread in IoT. An experimental stack of the security protocol is however provided by [50] and [32] for Contiki OS [8]. Additionally, Contiki turns out to be adapted to the evaluation of EHC Diet-ESP: it is a fairly popular OS in IoT, the memory footprint is small and the OS can run on constrained devices. However, it still provides a complete IPv6 stack and commodities like Radio Duty Cycling (RDC, a well-documented method to reduce the energy bill of a sensor equipped with a radio link). The code is Open Source and there is a large supporting community. Lastly, Contiki has been adapted on the hardware platform that was selected for the evaluation. For all these reasons, EHC Diet-ESP has been implemented and evaluated on Contiki OS 2.7. 2 . The default configuration of Contiki OS is modified to maximize the relative part of the power that is used for the preparation and the transmission of the data. The captors and unnecessary peripherals are turned off. The M3 CPU frequency is set to its minimum (8M Hz, compared to its nominal 72M Hz). The sensor can either be powered by a 620mAh battery, or an external power source. Because of the battery lifetime being subject to varying external factors – such as room temperature – that are neither relevant nor under control in a remote area, the tests were conducted with the nodes powered by the external power source, which is then considered as an idealized battery. The routing table are hardcoded on the nodes under test, so that the network neighborhood discovery mechanism of IPv6 does not interfere with the measure by regularly sending unwanted radio frames. Similarly, a free radio channel is carefully selected in order to avoid spurious radio frames generated by other devices that may operate in range. 5.3. Environment and test parameters The test is designed to capture the amount of energy and time required to prepare (encrypt and authenticate) and transmit a payload of a fixed size over UDP. The test is build as the scenario of the use case in Figure 1a, such as E2E unidirectional communications without the need of a Tunnel. The capture is done for four profiles of communication: unprotected (clear-text), uncompressed ESP and two profiles of EHC Diet-ESP. The parameters of the profiles, thus the Diet-ESP EHC Context, are shown in Table 4. – Unprotected: data is sent in the clear. There is no transformation of the data before it is sent (neither encryption nor authentication) and the ESP stack is totally deactivated in this scenario. – Uncompressed ESP: data is encrypted and authenticated by ESP, thus the security headers are fully transmitted along payload. The AES-CCM data payload is as described in RFC 3610 [73]. As ESP corresponds to some Diet-ESP EHC Context, the use of ESP can also be seen as the lower bound compression of EHC. 2

The implementation is available at https://bitbucket.org/sylvain_www/diet-esp-contiki


Fig. 6. Sequence of prepare-and-send a 10 byte payload

23

Fig. 7. Idle, preparation and radio transmission in a loop

– Partial EHC Diet-ESP, noted as ”Diet-ESP(p)“. This profile achieves a regular expected compression. There are various ways to achieve this profile, however, in our experimentation this profile consists in compressing all fields except the ICV which is left to 12 bytes (AES-XCBC-MAC-96). This profile is likely to match a certain number of situations and should be seen as a 12 byte overhead. In our case, these 12 bytes are those of the ICV, however, one may choose to use these bytes otherwise. For example, the ICV could 8 bytes and the SPI and SN being 2 bytes each. – Full blown EHC Diet-ESP, noted as ”Diet-ESP(f)“. This profile achieves almost the best possible compression of ESP. All ESP fields are compressed completely, except the ICV that is compressed to 1 byte that is to say its minimal non zero length value. As discussed before, this profile should only be used with care. Even though this profile may be hardly deployed in practice, it provides an upper bound compression for EHC Diet-ESP with authentication. For all protected profiles described in RFC 3610 [73], the encryption is done using AES-CTR [26] and the ICV is calculated with AES-XCBC-MAC-96 [17]. When EHC Diet-ESP is used to protect the payload, the IV is not included in the packet. In this case, the encryption algorithm in Table 4 is noted with an asterisk: while the encryption method remains identical, the missing IV means the encryption protocol is not ENCR_AES-CTR [26], but instead ENCR_AES-CTR_IIV [24]. The important thing to note is that although IV compression has been motivated by the research of Diet-ESP, it can also be used with ESP. In fact the IV compression is not indicated in the EHC Diet-ESP Context. Instead, it is designated as a specific encryption protocol which is negotiated in the regular IKEv2 exchange.

6. Experimental Measurements This section illustrates how EHC significantly reduces the energy-network overhead. Section 6.1 analysis the benefits when securing three different payload sizes —10, 50 and 190 bytes. Section 6.2 refines these results and generalizes the analysis of the previous Section by providing EHC Diet-ESP energynetwork overhead for any size of application data payload varying from 1 byte to a few hundred bytes. 6.1. Energy and time savings: Case Study of 10, 50 and 190 byte Payloads The study first tries to determine the amount of energy and the time taken by the M3 node to process and send a fixed payload. The device under test (DUT) is configured to send the same payload a large

24


number of times. The dissipated power during the whole experience is measured, then the data is analyzed to deduce the average energy consumption for one elementary operation consisting in preparing and sending one payload. Figure 6 shows an extract of the instant power during the experiment. The graph shows a succession of peaks, showing the activity of the radio activity of the DUT. The radio peaks account for the majority of the processing time of the test and the preparation phase of the data cannot be distinguished. In other words, this confirms that saving battery should primarily be done by reducing the time the radio is powered on. As this time depends on the number of transmitted bytes, the priority is to reduce the payload and provide payload compression facilities. This is, much more important than reducing computation with specific cryptographic algorithms. Note that reducing computation is not the primary goal of EHC Diet-ESP. However, it may be useful to reduce this overhead in order to make security implementable on constraint devices. This goal is complementary to compression and has very few impact on saving battery lifetime. Table 5 sums up various details related to a 10 byte data payload. The size of the datagram corresponding to each profile can be derived from Table 4. Without any protection, these 10 bytes of application data are using UDP (8 bytes) over IPv6 (40 bytes) which makes 58 bytes to be broadcast. When protected with ESP, the ESP Header is formed by the SPI (4 bytes) and the SN (4 bytes). There is no ESP Padding which leads to a 2 byte ESP Trailer: 1 byte for the Pad Length and 1 byte for the Next Header. In addition, the use of AES-CTR with a 12 bytes ICV also includes a 8 byte IV. As a result ESP generates a 30 byte overhead with a 88 bytes datagram. With Diet-ESP(p), SPI, SN, Pad Length, NH, UDP and IV are compressed thus leading to a 62 byte payload. Finally, with Diet-ESP(f) the ICV is compressed which leads to a 51 byte payload. The IP payload length for the 50 and 190 byte application data are computed similarly and are summed up in Table 5. The energy and time spent to send 10 bytes secured by ESP, nearly doubles when compared to a transmission of unprotected data. When the payload is secured and subsequently compressed with EHC Diet-ESP, the results show a limited overhead less than 5% compared to the unprotected profile. This clearly leads to a significant advantage of EHC Diet-ESP over ESP for 10 byte application data payloads. On the other hand, the advantage of EHC Diet-ESP over ESP for a 50 byte payload is limited (less than 2%). In this case both ESP and EHC Diet-ESP have less than 5% energy-network overhead compared to unprotected data. At last, some profiles provide significant advantage with the 190 byte application data payloads. Indeed, Diet-ESP(f) provides a less than 1% overhead over unprotected data payloads, whereas ESP and Diet-ESP(p) provide a 30% energy-network overhead. Even if the energy-network overhead is associated to the length of the payload, the relation between the number of bytes and the energy-network overhead is not linear. In order to understand the relation between the IP payload length and the energy-network overhead, Table 5 provides the number of IEEE 802.15.4 frames transmitted by the radio. Data are transmitted in frames of maximum size 127 bytes, irrespective of the number of bytes in the payload. The configuration of the IP stack in Contiki actually implies that each link frame only contains 80 bytes of actual IP payload data. As shown in Table 5, there is a direct and obvious correlation between the increased number of radio frames and the raise of energy and duration. When judging equal frame numbers and equal payload size, the cost of protection, be it ESP or EHC Diet-ESP, is less than a few percent. EHC Diet-ESP provides a less than 2% energy-network overhead, whereas ESP achieves a less than 5% energy-network overhead. It is already possible to conclude that EHC Diet-ESP is advantageous, because it helps limit the number of radio frames to send for some specific payloads. When ESP requires an additional radio frame, but EHC Diet-ESP manages to pull back to the same number of frames as the unprotected profile, then it

25

Migault, Guggemos, Killian et. al / Diet-ESP: IP Layer Security for IoT Table 5 Energy Comparison for sending different payloads. Percentages always compares with mode “unprotected”. 10 bytes

energy duration IP radio

(mJ) (%) (ms) (%) (bytes) (frames)

unprotected 10.5 155 58 1

ESP 20.4 +94.29 311 +100.65 88 2

DietESP(p) 10.7 +1.90 160 +3.23 62 1

DietESP(f) 10.8 +2.88 162 +4.52 51 1


50 bytes DietESP(p) 21.1 20.7 +3.94 +1.97 311 311 +1.97 +1.97 128 102 2 2 ESP

DietESP(f) 20.4 +0.49 311 +1.97 91 2


190 bytes DietESP(p) 41.5 40.8 +31.75 +29.52 611 611 +33.99 +33.99 268 242 4 4 ESP

Fig. 8. Energy vs payload

Fig. 9. Relative energy vs payload

Fig. 10. Time vs payload

Fig. 11. Sleeping sensor with regular wake-up

DietESP(f) 31.8 0.95 465 +1.97 231 3

cuts the energy bill by up to 100% (10 byte payload), or 30% (190 byte payload). When ESP and EHC Diet-ESP end up sending the same number of radio frames (as in the 50 byte payload scenario), then EHC Diet-ESP does not cost more than ESP, the energetic bill is actually identical for the two profiles. 6.2. Savings with EHC Diet-ESP, for a range of payloads In order to refine the view on how the energy spent is varying with the payload, the previous experiment is repeated for a range of payloads. The results are shown in Figure 8. The observations are as follows: – Each type of profile used for the protection of the payload is showing a shift in the energy spent, when compared to the unprotected communications.

26


– The lines are showing marked steps. Each step accounts for an additional frame sent by the radio. As radio frames are limited to 127 bytes, there is a threshold effect on the energetic bill each time a radio frame is added to the transmission. – Additionally, there is a more subtle increase as the payload grows. This shows the small increase in energy required to prepare (encrypt and authenticate) a growing payload. ESP is always more costly than the unprotected profile due to additional bytes added by ESP. The results achieved by EHC Diet-ESP give a feeling on how the overhead of the protection is reduced. The figures EHC Diet-ESP are indeed much closer to the figures produced by the unprotected profile. Interestingly, for specific payloads, the Diet-ESP(f) profile achieves an even lower energetic bill than the unprotected profile! For those very specific payloads (these are actually small windows), it is more advantageous, energy wise, to protect the data with Diet-ESP(f), than to send it in the clear. This is explained by the capacity of EHC Diet-ESP to compress the transport layer (in our case, a UDP header), reducing significantly the number of bytes in the IP packet and hence the number of radio frames required to send the payload. Figure 9 draws the energy-network overhead of the protected profiles, relative to the unprotected profile. This graph shows clearly that there are ranges of payloads for which protecting the data is very costly. Those ranges are however smaller in the case of Diet-ESP(p) and can even turn out beneficial energy wise for Diet-ESP-(f). The overhead (or gain) is particularly impacting if the payload is small. Lastly, outside the diverging areas (the ’peaks’), there is a constant energy overhead, showing a nearly constant value around 2%. This represents the cost of the software processing the data before transmission. Figure 10 shows the time necessary to prepare and send the data, for a range of payloads. The graph is very similar to the graph with energy consumption. However, when Figure 8 is showing a slight increase each time 1 byte of payload is added, Figure 10 shows a flat line between two steps (the steps indicating an additional radio frame). The time required to prepare one additional byte of payload is so short compared to the time required to transmit a frame that it cannot be seen on a graph at this scale. In other words, the time required to prepare the data is negligible compared to the time required to transmit it. 7. Conclusion EHC is a new lightweight application-agnostic security protocol for protecting data exchange over IoT and Internet networks. This paper describes the EHC protocol and evaluates its performance. The EHC Strategy Diet-ESP was evaluated with different profiles on the IoT-LAB test platform. The experimental measurements demonstrate that even for small data payloads of 10 bytes or less, Diet-ESP introduces a small energy overhead (

Diet-ESP: IP Layer Security for IoT

Diet-ESP: IP Layer Security for IoT

Suggest Documents

Implementation of Security Layer on IoT based Sensor Network for

Low Power Link Layer Security for IoT: Implementation ... - CiteSeerX

Low Power Link Layer Security for IoT: Implementation ... - CiteSeerX

A Thin Security Layer Protocol over IP Protocol on TCP/IP Suite for ...

IP Security

IoT Security Guidelines for IoT Service Ecosystem Version 1.0 ... - GSMA

IP convergence layer for HIPERLAN/2 - DIT

IoT Security

Automotive IoT Security - GSMA

Trends in IoT Security

IoT Security Guidelines for IoT Service Ecosystem Version 2.0 ... - GSMA

New Security Architecture for IoT Network

Security Evaluation Framework for Military IoT Devices

cyber security services for iot - Comarch

The Consumer Security Index for IoT

cyber security services for iot - Comarch

cyber security services for iot - Comarch

Embedded Security for Internet of Things - IOT Security Laboratory

Mobile IP: Security & Application

IoT Infographic: Security Policies - ForeScout

Security for KNXnet/IP - KNX Association

Optimal Secure Multi-Layer IoT Network Design

Optimal Secure Multi-Layer IoT Network Design

Coordinated Survivability in IP-over-Optical Networks with IP-Layer