## 2 Security Protocols
### Network-Layer Security  
At network layer, an IoT node can secure data exchange in a standard way by using the Internet Protocol Security (IPsec) [11]. IPSec was originally developed for IPv6, but found widespread deployment, first, as an extension in IPv4, into which it was back-engineered. IPSec was an integral part of the base IPv6 protocol suite, but has since then been made optional. IPSec can be used in protecting data flows between a pair of hosts (host-to-host communication), between a pair of security gateways (network-to-network communication), or between a security gateway and a host (network-to-host communication). IPSec can provide confidentiality, integrity, data-origin authentication and protection against replay attacks, for each IP packet (it works at network layer). Such security services are implemented by two IPSec security protocols: Authentication Header (AH) and Encapsulated Security Payload (ESP). While the former (AH) provides integrity, data-origin authentication, and optionally anti-replay capabilities, the latter (ESP) may provide confidentiality, data-origin authentication, integrity, and anti-replay capabilities. IPSec AH and ESP define only the way payload data (in clear or enciphered) and IPSec control information are encapsulated, while the effective algorithms for data origin authentication/integrity/confidentiality can be specified separately and selected amongst a set of available cipher suites. This modularity makes IPSec usable also in the presence of very resource-constrained devices, if a proper algorithm that guarantees both usability and sufficient security level is selected. This meansthat, from an algorithmic point of view, the problem moves from the IPSec protocol itself to the actual cryptographic algorithms. Section 3 is fully dedicated to algorithm-related issues. The keying material and the selected cryptographic algorithms used by IPSec for securing a communication are called IPSec Security Association (SA). To establish a SA, IPSec can be pre-configured (specifying a pre-shared key, hash function and encryption algorithm) or can be dynamically negotiated by the IPSec Internet Key Exchange (IKE) protocol. Unfortunately, as the IKE protocol was designed for standard Internet nodes, it uses asymmetric cryptography, which is computationally heavy for very small devices. For this reason, proper IKE extensions should be considered using lighter algorithms. These aspects are treated in Section 3. Other problems related to the implementation of IPSec in constrained IoT nodes include data overhead (with respect to IP), configuration, and practical implementation aspects. Data overhead is introduced by the extra header encapsulation of IPSec AH and/or ESP. However, this can be limited by implementing header compression techniques, similarly to what is done in 6 LoWPAN for the IP header. In [12], a possible compression mechanism for IPSec in 6 LoWPAN is proposed and numerically evaluated. Regarding practical aspects, it is worth to observe that IPSec is often designed for VPNs, thus making it difficult for them to be dynamically configurable by an application. Moreover, existing implementations are also hardly compatible with each other and often require manual configuration to interoperate. An alternative to using IKE+IPsec is the Host Identity Protocol (HIP) [13]. The main objective of HIP is to decouple the two functions of host locators (for routing purposes) and host identifiers (for actual host identification) currently performed by IP addresses. For this purpose, HIP introduces a new namespace between IP and upper layers specific for host identification based on public cryptography. In HIP, the host identity (HI) is directly associated with a pair of public/private keys, where the private key is owned by the host and the public key is used as Host Identifier (HI).