HTTP3
HTTP3 for IoT?
Last updated
Was this helpful?
HTTP3 for IoT?
Last updated
Was this helpful?
Legacy network protocols have been deployed with great success. In particular, the TCP/IP layer has been the enabling the web and mobile applications we are now accustomed to. However, it has been designed for different requirements than those we are now facing.
Many improvements to the TCP/IP stack have been proposed and implemented, but they come at the cost of reduced performance.
Therefore, one can envision an adaptation layer between IPv6 and the LPWAN connectivity to support IoT use cases. However, CoAP being specific, interoperability with the rest of the web still requires the use of mappings. For security more specifically, there are interoperability concerns between TLS, OSCore and Edhoc. This not only presents an interoperability problem but a security issue too, since end-to-end encryption becomes harder when intermediaries are required, and leads to unnecessary least privilege access.
suggest an UDP transport may be a better fit,
ESP32-devkit), but profiling proves to be challenging on real hardware.
Going beyond a basic prototype would require:
a choice of which functionalities to enable: available implementations, made for web workloads, do
not enable clear profiles (client, server, both), nor do they allow to handle specific architectures
(32 bits processors, non-POSIX networking APIs, use of hardware cryptographic primitives, etc.)
or to adapt the capabilities to constrained requirements.
measurements and root cause analysis, especially for advanced features like flow and congestion
control, 0-RTT, multiplexing and packetization. In the IoT domain, this is even more challenging
since logging is very limited. The objective is to test on a simulation platform (qemu and FPGA,
such as simfire), as well as real hardware, opensource (RISC-V) or not.
A re-architecture is therefore required, and new initiatives for technologies able to support next generation protocols have started to emerge, especially in ETSI and IETF (see for instance and ).
The existing platforms for managing connected objects focus their priority on essential services for fleets of connected objects: manage the multi-protocol connectivity of objects (SigFox, LoRa, Nb-IoT, 5G, etc.), master the inventory of deployed objects and configure or update them via a "Device Management" module (LWM2M, OMA-DM, TR-069 / CWMP, etc.), and allow the feedback and the provision of data generated by the objects (DTLS, CoAP, MQTT, AMQP, etc.). Due to the drastic energy and bandwidth constraints, the vast majority of IoT networks do not follow the Internet model based on IP protocols. Indeed, the TCP/IP stack is too greedy for constrained devices. HTTP has long been considered . Due to those limitations, a protocol called CoAP, based on UDP, has been gaining in popularity. A recently approved IETF standard, SCHC, provides a compression mechanism to reduce CoAP/IPv6 headers to just a few bytes, which can be transported by LPWAN networks. We successfully tested SCHC for the mediam use cases (see dedicated section on SCHC).
The choice of using a protocol over another under examination and the workloads intrinsically generated within them. However, the improvements in HTTP protocol have received little interest. Previous work has evaluated the fitness of HTTP2 and HTTP3 for the IoT:
An of HTTP/2 to Contiki validates the feasibility of this approach, and results
Lars Eggert has adapted an HTTP/3 client and on 2 different boards (argon and
HTTP/3, now available as an IETF draft standard, has therefore the potential to solve the fragmentation of IoT frameworks and improve security. Unlike HTTP/1.1, the new protocol provides header compression (QPACK). The redesign around UDP streams (QUIC) is a natural fit for battery powered devices and opens the door to more efficient congestion controls. Unlike CoAP, it enables a direct compatibility between constrained devices and enterprise networks. This is critical if we want IoT devices to implement end-toend encryption and even more to support identity and access management (IAM) for things. Our work prototyped an implementation of HTTP3 for IoT devices, as an alternative to CoAP, as well as concrete examples and guides for device designers. The priority use case is related to the implementation of IAM protocols adapted for IoT workloads, such as (which ported OAuth2 to CoAP) or the more recent being developed at IETF. Our implementation is based on .
HTTP/3 is not easy to implement correctly. demonstrate the importance of
that allows rapid experimentation for network and security researchers, including current networks (Wifi, BLE, LPWAN) and evolutive approaches(non-IP networks such as ). We may also support a prototype implementation of the format.
