The problem with TCP/IP for IoT? - Aer Networks

This section will discuss the problems with the IP protocol and why it it not a good fit for the IoT. ## Small MTU The maximum transfer unit (MTU) refers to the maximum amount of bytes you can fit in a data-packet. The MTU can be as little as 64 bytes in many wireless IoT systems. This is in clear contrast with today’s IP networks which typically assume a minimum MTU of 1500 bytes or higher. ## Multi-link subnets Multi-link subnets is the notion that a subnet may span multiple links connected by routers. RFC 4903, “Multi-Link Subnet Issues” [29], documents the reasons why the IETF decided to abandon the multi-link subnet model in favor of 1:1 mapping between Layer-2 links and IP subnets. An IoT mesh network, on other hand, contains a collection of Layer-2 links joined without any Layer-3 device (i.e., IP routers) in between. This essentially creates a multi-link subnet model that is not anticipated by the original IP addressing architecture. ## Multicast Multicast is a group communication model where data-transmission is addressed to a group of destination devices simultaniously. A lot of IP-based protocols make heavy use of IP multicast to achieve one of the two functionalities: notifying all the members in a group and making a query without knowing exactly whom to ask. Using multicast raises a number of concerns: - Devices sleeping will not receive the data-transmission - Receivers may have different data-transmission rate - Broadcasting data is too expensive, so a routing mechanism is necessary - Encryption for IP multicast still needs to be invented ## Mesh network routing IP based host-routing is a major challenge in constrained IoT devices as each host needs to maintain a routing table. This consumes memory and causes network overhead when the network changes. Also, forwarding traffic may involve decrypting the data from the incoming link and then encrypting it on the outgoing link – an expensive operation for battery-driven devices. ## Transport layer problems Due to the energy constraints, devices may frequently go into sleep mode, thus it is infeasible to maintain a long-lived connection in IoT applications. Also, a lot of communication involves only a small amount of data making the overhead of establishing a connection unacceptable. Unfortunately, current TCP/IP architecture does not allow to embed application semantics into network packets, thus failing to provide sufficient support for application level framing, which would allow the application more control over the data transmission. ## Application layer problems Many IoT applications implement a resource-oriented request-response communication model. ZigBee, CHIP/Matter are such examples. Influenced by the web, many IoT protocols has been working on bringing the same REST architecture into IoT applications. CoAP is an example of such a standard, which is also being used in the Thread protocol. There are a number of problems with this approach: - It usually requires resource discovery, such as DNS or Core-RD which in turn uses broadcast. - It requires that the client (requester) and the server (resource) is online at the same time - It requires a fundamental change to the security model in order to make the in-network caches secure and trustworthy ## Security In the IP based host-centric model, TLS/DTLS is used to secure the communication channel between the requester and the resource. However, this model does not fit with the requirements of IoT: - TLS/DTLS requires two or more exchanges of data to negotiate the communication channel, a resource and energy extensive task. Also, both ends have to maintain the state of the channel until it is closed, stopping devices from entering sleep-mode - Encryption for IP multicast still needs to be invented so security only works in host-based communication … These connections are secured with DTLS, which is energy- and bandwidth consuming task, so a better way is clearly needed. So why not just use CoAP multicast? Well, you can, but there is no standard for encrypting CoAP multicast traffic. In fact, (DTLS) encryption in IP multicast still needs to be invented, meaning that you can not send encrypted information over the air to other CoAP devices using multicast!