## 2 Security Protocols
### Transport-Layer Security  
In the current IP architecture, data exchange between application nodes can be secured at transport layer through the standard Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. TLS is the widest used secure protocol, running on top of the TCP providing to the application layer the same connection and stream-oriented interface of TCP [15]. In addition, TLS provides complete secure communication through: peer-entity authentication and key exchange (using asymmetric cryptography); data authentication, integrity, and anti-replay (through message authentication code); confidentiality (using symmetric encryption). Peer-entity authentication and key exchange is provided by the TLS Handshake phase, performed at the beginning of the communication. DTLS, instead, has been introduced more recently in order to provide a security service similar to TLS on top of UDP [16]. Although it is still poorly supported in standard Internet nodes, it is currently the reference security protocol for IoT systems since it uses UDP as transport and does not suffer from the problems originated by the use of TCP in network-constrained scenarios (due to the extremely variable transmission delay and lossy links). Both IPSec and DTLS provide the same security features with their own mechanisms at different stack layers. Moreover the IPSec IKE key agreement reflects almost the same DTLS Handshake function. The main advantage of securing communications at transport layer with DTLS consists in allowing more precise access control. In fact, operation at the transport layer allows applications to directly and easily select which, if any, security service has to be set up. Another practical advantage is that the adoption of DTLS can allow for the reuse of the large experience and implementations that came with TLS. For these reasons DTLS has recently received significant attention for securing communication of constrained node/network applications and it has been standardized as the security protocol for CoAP associated to \"coaps\" URIs [10]. Unfortunately, there are still some few issues that should be faced in order to make DTLS more friendly for constrained devices. The most relevant ones are related to limited packet size imposed by underlying protocols such as IEEE 802.15.4. In fact, as for IPSec, DTLS introduces overhead during both handshake and data transport phases. DTLS offers fragmentation at the Handshake layer, however, this can add a significant overhead. Another solution could be to use the fragmentation offered at IPv6 or 6 LoWPAN layer. Moreover, in order to reduce DTLS overhead, some packet optimization and compression mechanism can be introduced. For example, in [17] the authors propose to use the 6 LoWPAN compression mechanisms for the DTLS protocol. From the security point of view, one problem of using DTLS or IPSec is that end-to-end communication is not guaranteed when intermediate nodes such as proxies or application level gateways are introduced. In fact, both IPSec and DTLS provide secure communications at IP and transport layers respectively, and, in presence of a multi-hop application-level communications, they can assure security only within each hop. In addition, some complications in providing end-to-end security may arise also when connectivity is realized directly at IP and transport layers. There are scenarios in which a part of the network (internal) composed by constrained devices is interconnected at IP level to the rest of the (external) network, for example the Internet. Although data protection can be guaranteed through IPSec or DTLS protocols, other network attacks, like flooding or replay, may occur due to the asymmetry of the resources available at the end systems; for example a full-powered host attached to the Internet may attack a constrained device by trying to consume all power or processing resources of the limited device.