H2oT: HTTP/2 for the Internet of Things

When the IETF started work on the Internet-of-Things ("IoT") with the 6lowpan WG, it was clear that in addition to the lower-layer adaptation work for IPv6, much work elsewhere in the stack was necessary. (In this document, the "things" in "IoT" are nodes that are constrained in some manner--e.g., cpu, memory, power--such that direct use of unmodified mainstream protocols is challenging.) Once the IPv6 adaptation was understood, the next question was what protocols to use above IP(v6) for different functions and at different layers to have a complete stack. That question may not have a single answer that is always best for all scenarios and use cases. There are many such use cases, in accordance with the fact that IoT means too many things. Accordingly, the IoT landscape includes a proliferation of options for any particular functionality (transport, encoding, security suites, authentication/authorization, etc). Different vendors and standards organizations (or fora) offer IoT solutions by grouping these different components into separate stacks. Even if the components have the same name or originate in the same original standard (or even in the same code base), each organization adapts it ever so slightly to their own goals, often rendering the resultant components non-interoperable. Many of these components are being created expressly for IoT (within the IETF and elsewhere) under the assumption that the mainstream options could not possibly be usable for IoT scenarios. This results in multiple disparate networking and software stacks. Given the incipient state of IoT, for the foreseeable future multiple competing stacks will continue to exist at least in gateways and cloud elements. The additional complexity to IoT amplifies the attack surface. Nevertheless, properly configured and implemented, mainstream options may not just be workable, but may even be the best option at least in some scenarios. The appearance of one-off stacks (as opposed to a properly configured and adapted mainstream stack) is reminiscent of WAP 1.x, a complete vertical stack offered for phones as they were starting to access the Internet (albeit from within a walled garden) in the late 90's. At that time the IETF and the W3C started efforts to develop the mainstream alternatives. As a result, today no phone uses WAP. Instead, phone stacks are mainstream TCP/IP protocols (properly configured and adapted, of course). In contrast, today in IoT we see not just one non-mainstream stack, but several (as if we had not just WAP, but WAP1, WAP2, WAP3, etc.). And we may have to live with them for some time, but it is essential to ponder what the mainstream stack might look like if we are to eventually reap the benefits of a true Internet of Things instead of a not-quite-but-kinda-close-to-Internet-non-interoperable-hodge-podge-of-Things. HTTP/2 is now widely available as a transport option. Moreover, the ongoing effort to layer HTTP/2 over UDP (i.e., over QUIC) adds a useful capability for IoT scenarios. We show the current suitability of HTTP/2 for IoT scenarios and examine possible improvements. Let's look at some application communication patterns to establish some common language (see also section 2 of for a related discussion): A constrained node engages in direct communication with another constrained node. A constrained node and a gateway node engage in direct communication. A gateway node is directly on both a constrained network (e.g., a lowpan) and on a non-constrained network (a normal network using mainstream stack implementations, typically connected to the Internet). A gateway node (see above) engages in communication with unconstrained networks, typically a cloud service on the Internet. A node on a constrained network engages in direct communcation with unconstrained networks, typically a cloud service on the Internet. In the above, a "node" may, in fact, be multiple nodes when engaging in group communication. Group communications (e.g., via multicast) are commonly used for discovery or routing (see also ). We can further categorize the above communication patterns into two basic types of networking exchanges: A constrained network scenario includes node to node and node to gateway exchanges. Group communications are another typical aspect of these constrained networks. An Internet scenario includes gateway to cloud and node to cloud exchanges. This document makes the case for HTTP/2 as the most general protocol of choice for Internet of Things applications. HTTP/2 is most at home in Internet scenarios and is also suitable for at least some Constrained network scenarios.

A recent survey by the Eclipse IoT working group queried IoT developers about the protocols and technologies they are using and planning to use . Some of the currently used application transport protocols (above the link layer) for IoT applications are as follows: HTTP/1.1 (61% of developers) MQTT (52% of developers) CoAP (21% of developers) HTTP/2 (19% of developers) Others: In-house, AMQP and XMPP (43% of developers) It is interesting to note that in the same survey done in 2015, HTTP/2 was not even present, whereas it is now at 19% (the other protocols are mostly unchanged). No doubt it is being used in scenarios where there are no major constraints (precisely where HTTP/1.x is also being used). Optimizing it for IoT can further promote its use. The sections below provide some more details on top-of-the-list protocols other than HTTP/2.

HTTP/1.1 is a text-based protocol, and is widely successful as it is the basis not just for the web, but for much non-web traffic in the internet today. Most (but not all) of the instances of HTTP today implement version 1.1 as specified in RFC2616 . Since its publication back in 1999 it has evolved organically, producing countless variations and exceptions to its rules. Modern browser and server implementations have very complex and convoluted code to deal with parsing and handling the many nuances of the protocol. Because of all this confusion, the HTTPbis working group set out to clarify the existing specifications, and after a multi-year effort to clarify its many sources of confusion, it has published a cleaner specification in RFCs 7230-7235 . In spite of this, the protocol still has a plethora of legacy issues and remains too verbose. HTTP/1.1 is very clearly a mismatch for the constrained devices and networks that characterize IoT. Despite its shortcomings, it is the most popular protocol for IoT applications (61% per the aforementioned survey, although the survey does not clarify if this is for Internet or constrained network scenarios). Why would such an ill-suited protocol be clearly the most popular for IoT applications? It is by far the most commonly known protocol. It has many implementations (many in open source), with massive support in all platforms, tools and APIs. It is easy to find know-how and support. In short, it has the power and convenience that comes with being a mainstream protocol. Another major advantage is that it is the protocol that has the best chance of traversing firewalls and middle boxes in the internet due to its use of port 80 when in the clear, and, especially, its use of port 443 when over TLS. This is a primary concern in Internet scenarios.

MQ Telemetry Transport (MQTT) is a publish/subscribe messaging protocol that runs on top of TCP. It was created by IBM. Version 3.1.1 is available as an OASIS standard and as an ISO publication . It is popular in the Internet scenario (node to cloud, gateway to cloud) and it aims to connect embedded devices and networks with applications and middleware. It is a compact, binary protocol, and is very popular in certain application domains. It has been known as a protocol suitable to be used in resource constrained devices and unreliable networks. It is the second most popular protocol in the survey (behind HTTP/1.1) with 52% of developers using it. In the internet scenario, however, TLS is probably required. This additional TLS overhead renders all protocols slightly larger, so, e.g., MQTT loses some relative size advantage. The MQTT protocol requires an underlying transport that provides an ordered, lossless, stream of bytes from the Client to Server and Server to Client. It cannot be used over UDP. There is an alternative (and not standardized) variant called MQTT-SN (previously called MQTT-S) which can use UDP, Zigbee or other datagram transports, but this is a substantially different protocol which has been tailored to meet the needs of small, battery-powered sensors connected by wireless sensor networks (WSNs), and relies upon a MQTT-SN Gateway or forwarder for external communications. MQTT is closely tied to PUBLISH/SUBSCRIBE operations and this is the only mode of message transfer. This means that MQTT cannot be used for “node to node” communications because a server is required (the server forwards messages between publishers and subscribers, manages subscriptions, and performs user authorization functions.) The exclusive use of publish/subscribe operations can complicate some IoT operations, such as request-response traffic, and transferring large payloads (e.g. firmware updates). It is sometimes desirable to use a different protocol (like HTTP) for transferring large payloads, even though MQTT supports a maximum per-message payload size of 256 MiB. The OASIS MQTT-TC is considering proposals involving changes in handling request-response traffic and large message transfers. MQTT is deployed over TCP (port 8833 when over TLS, port 1883 without TLS). Even when using TLS, it has the well-known firewall traversal issues common to any protocol not over port 443.

CoAP is a compact, binary, UDP-based protocol based on RESTful principles and closely patterned after HTTP. It has been designed to be used in constrained devices and constrained networks. The protocol specification has been published , although additional functionalities such as congestion control, block-wise transfer, TCP and TLS transfer and HTTP mapping are still being specified. The protocol meets IoT requirements through the modification of some HTTP functionalities to achieve low-power consumption and operation over lossy links. To avoid undesirable packet fragmentation the CoAP specification provides an upper bound to the message size, dictating that a CoAP message, appropriately encapsulated, SHOULD fit within a single IP datagram: If the Path MTU is not known for a destination, an IP MTU of 1280 bytes SHOULD be assumed; if nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size. CoAP interaction with HTTP must traverse a proxy, with the concomitant issues of breaking end-to-end security (), but at least the common REST architecture makes it easier. CoAP works on port 5683 and offers optional reliable delivery (thru a retransmission mechanism), support for unicast and multicast, and asynchronous message exchange. Multicast (see is typically used by IoT SDO's for routing and discovery. A common use of multicast within CoAP is for discovery, something addressed in mainstream (and even some IoT) scenarios via mDNS and DNS-SD . More general uses of multicast within CoAP (and, in general, at the application transport, e.g., to address group communication for IoT), introduces complexity for security, IPv6 scoping, wireless reliability, etc. A typical CoAP message can be between 10 and 20 bytes. It is the third most popular protocol in the survey with a 21% preference. Nevertheless, since CoAP is UDP-based, in the Internet scenario it also suffers from firewall traversal issues, verbosity (as compared to TCP) to maintain state in NAT boxes and lack of integration with existing enterprise infrastructures. There is ongoing work to specify the use of CoAP over TCP as well as CoAP over TLS, in an attempt to overcome issues with middleboxes and improve its applicability to Internet scenarios. As noted above, there is much ongoing work on CoAP, and much of it seeks to define a transport on top of UDP. This is a very complex task not to be underestimated. QUIC is also embarking on this task, but it appears to be benefitting from many more resources within the networking community at large.

The aformentioned protocols have been compared in both experimental and emulated environments . Previous reports show that performance is highly dependent on the network conditions: in good link conditions with low packet loss, MQTT delivers packets with lower delay than CoAP, but CoAP outperforms when high packet losses are present; in terms of packet sizes, if packet loss is under 25% and messages are of a small size, CoAP demonstrates a better link usage than MQTT. However, other experiments report a better performance of MQTT in high traffic/high packet loss scenarios . CoAP has also been compared to HTTP/1.1. In terms of power consumption and response time, naturally CoAP behaves better than HTTP/1.1 thanks to the reduced packet sizes. Coexistence among the protocols has also been tested with varied network configurations. For the most part, interaction of CoAP with HTTP has been studied , demonstrating successful exchange when there is a CoAP server running on a constrained node and the HTTP client is requesting resources from it, or when there is a CoAP client requesting resources from an HTTP server. In both cases a proxy is necessary to enable translation between the protocols. Another network configuration with a CoAP client - CoAP proxy - CoAP server has been compared to the CoAP client - CoAP/HTTP proxy - HTTP server configuration, in which case the response times of the only-CoAP configuration resulted to be lower even when the number of concurrent requests increases . To date, no reports have been found comparing MQTT or CoAP to HTTP/2.

These protocols often do not exist in a vacuum. Typically, they are mandated as part of a given stack specified by any of several IoT consortia (e.g., OCF, AllSeen Alliance/AllJoyn, Thread Group). We know that these multiple IoT protocols (and stacks) provide very useful sources of information for prying eyes (See “US intelligence chief says we might use the IoT to spy on you” at http://www.wired.com/2012/03/petraeus-tv-remote/). Security and privacy issues are exacerbated because: IoT is the worst of all security worlds: (1) constraints push devices into taking shortcuts and (2) there is less physical security with such devices (after installation they are typically reachable by unfriendly hands). Each of these protocols is an island with its own security measures (or lack thereof) and very limited review. The previous two points can be summarized as follows: This is receiving much attention from the research and standardization communities. It is the sort of challenge that stimulates researchers into high gear. It is a daunting problem for sure, but at least it is on the radar of folks and consortia working on IoT. Nevertheless, many issues will arise because of this (e.g., discovery of serious flaws in IoT devices like locks is a common occurrence). This is a much more worrisome issue if one considers that a vast majority of issues arising with security have less to do with cryptography (the first point above) and more to do with software engineering, and silly bugs. Each stack added creates more attack surface. At the same time, each one of these stacks gather less attention and scrutiny than software used for mainstream scenarios (such as the web). We have seen no shortage of issues on OpenSSL and similar heavily-used software. We can expect much worse from stacks that are not nearly as well exercised nor examined. And if we have not one, but several of these stacks untested by millions of eyeballs, we are inviting disaster. A recent Harvard report on the state of surveillance and erosion of privacy concludes among its findings that the projected substantial growth of IoT will drastically change surveillance (surveillance is not merely limited to government agencies of course), and that the fragmentation of ecosystems hinders the deployment of countermeasures (e.g., end-to-end encryption) as that requires more coordination and standardization than currently available. This not only gives rise to rogue surveillance sites such as Shodan (https://www.shodan.io/), but also represents a great opportunity for government agencies’ surveillance needs . Furthermore, multiple stacks defeat one of the main benefits of the “I” in IoT: interoperability. Also, reusing mainstream protocols affords the benefits of using better-known technology, with easier access to reference implementations (including open source), people with the required skills and experience, training, etc. These are basically the same arguments that were used originally to justify the use of IP-based networking over custom-built stacks. The message was heard loud and clear but for the most part it was applied to only a limited set of components (e.g., IP, UDP, DTLS). Other components are still being custom built (albeit, on top of IP).

As noted above, for the foreseeable future the IoT landscape requires several stacks. Thinking about a canonical stack based on mainstream protocols is not an exercise in the delusion that one single stack will be enough. Rather, it is an attempt to define an option that can serve IoT better into the future, and one that can be recommended whenever there is a choice (often there isn't one). The goals in pursuing a canonical stack are the following: Maximize Standards-based Elements across technologies and IoT stacks Reduce IoT protocol idiosyncrasies and specificity Reduce the number of “translators” needed in an IoT hub To arrive at a canonical stack the mainstream standards-based stack must be properly profiled and optimized. This requires optimizing aspects such as: Authentication and Authorization framework by adapting OAUTH instead of inventing a new system . Device Management and Object Model/Descriptions (currently being defined). Discovery via mDNS and DNS-SD perhaps augmented with IoT considerations, e.g., . Another option to investigate is that of HTTP/2 over multicast. Whereas there have been some forays into HTTP over multicast, it is not nearly as well deployed, implemented and understood as mDNS. Application Transport based on HTTP/2. This document deals only with the application layer transport based on HTTP/2. HTTP/2 is a good match for IoT for several reasons: Binary and Compact (9 byte header) Header Compression Traversal past firewalls/middle boxes via TLS over port 443 Support of RESTful model in major development frameworks Know-how widely available

HTTP/2 has many negotiable settings that can improve its performance for IoT applications by reducing bandwidth, codespace, and RAM requirements. Specifically, the following settings and values have been found to be useful in IoT applications: SETTINGS_HEADER_TABLE_SIZE: this setting allows hosts to limit the size of the header compression table used for decoding, reducing required RAM, but potentially increasing bandwidth requirements. Initial value per HTTP/2 is 4096. IoT scenarios might benefit from changing this to a smaller value (e.g., 512), however, to avoid increased bandwidth usage, IoT scenarios should judiciously use HTTP headers and the dynamic header table . SETTINGS_ENABLE_PUSH: This setting allows clients to enable or disable server push. This functionality may not be required in some IoT applications. The initial value per HTTP/2 is 1. SETTINGS_MAX_CONCURRENT_STREAMS: this setting allows a sender to limit the number of simultaneous streams that a receiver can create for a connection. HTTP/2 recommends this value be no smaller than 100. IoT scenarios may wish to limit this to a much smaller number, such as 2 or 3. SETTINGS_INITIAL_WINDOW_SIZE: this setting allows hosts to limit the flow control window, potentially reducing buffer requirements at the expense of potentially underutilized bandwidth-delay products. Per HTTP/2 the initial value is 2^16-1 (65,535) octets. IoT scenarios may wish to limit this to smaller values in accordance with the node's constraints (e.g., a few kilo-octets). SETTINGS_MAX_FRAME_SIZE: this setting allows hosts to specify the largest frame size they are willing to receive. Per HTTP/2 the initial value is 2^14 (16,384) octets. Somewhat counterintuitively, IoT hosts may wish to leave this value large and rely on flow control to avoid unnecessary framing overhead. SETTINGS_MAX_HEADER_LIST_SIZE: this setting allows hosts to limit the maximum size of the header list they are willing to receive. Per HTTP/2 the initial value of this setting is unlimited. IoT scenarios may wish to limit this to smaller values in accordance with the node's constraints (e.g., a few kilo-octets).

For Constrained and Internet scenarios, it is assumed that HTTP/2 runs over TLS. Accordingly, the ALPN negotiation in section 3.3 of applies. As seen above, an IoT scenario may wish to depart from the default SETTINGS. To do so, the usual SETTINGS negotiation applies. In this case, the initial SETTINGS negotiation setup is based on the first message exchange initiated by the client. This is simpler than general HTTP/2 case: not having an in-the-clear Upgrade path means the client is always in control of first HTTP/2 message, including any SETTINGS changes it may wish. Additionally, the use of "prior knowledge" per section 3.4 of is likely to also work particularly well in IoT scenarios in which a client and its web service are likely to be closely matched. In such scenarios, prior knowledge may allow for SETTINGS to be set in accordance with some shared state implied by the the prior knowledge. In such cases, SETTINGS negotiation may not be necessary in order to depart from the defaults as defined by HTTP/2.

The proliferation of application and security protocols in the IoT has produced the deployments of islands of IoT devices, each using one of the several protocols available. However, usually an IoT deployment needs to communicate to another one, or at least needs to communicate with the Web, both because they have to upload data to the Cloud or because usually they are controlled by a Web application. In such cases, communication is facilitated by a cross-protocol proxy or a gateway translating from one protocol syntax and semantic into another one. However, the presence of Cross-Protocol or Application gateways has at least two main drawbacks that need to be analyzed and addressed carefully. while the translation may be trivial for the basic scenarios, there are a lot of cases where the translation can lead to information loss or an incompatibility due to the different way different proxies make the translation. The presence of such devices may also become a critical point for security.

This section assumes HTTP/2 over TCP. In addition to underlying stack considerations with respect to IPv4, IPv6, TCP, and TLS, there are implementation considerations for HTTP/2 for IoT. A primary consideration is the number of allowed simultaneous HTTP/2 connections. As each connection has associated overhead, as well as overhead for each stream, constrained hosts may wish to limit their number of simultaneous connections. However, implementers should consider that some popular browsers require more than one connection to operate. In addition to minimizing the number of simultaneous connections, hosts should consider leaving connections open if there is a possibility of further communication with the remote peer. HTTP/2 contains mechanisms such as PING to periodically check idle connections. Leaving established connections open when there is a possibility of future communication allows connection establishment overhead (and potentially TLS session establishment overhead) to be avoided. Should TLS be used, implementers may wish to consider utilizing hardware-based encryption to further reduce codespace and RAM requirements.

This section presents some simple results obtained using the Deuterium HTTP/2 library and is not intended to be complete, but rather a start for discussion. From an IoT perspective, the reduced message sizes presented help to conserve both bandwidth and battery life, as well as potentially saving some memory/buffer space. The results presented in this section make the following assumptions and considerations: Overhead from TCP and TLS are ignored An attempt to minimize the headers used has been made while still maintaining RFC compliance No entries are made into the HTTP/2 dynamic table, thus removing some potential optimization Connection establishment and teardown have been ignored, though clearly these are important considerations for IoT application protocols Only happy path transmissions are shown, thus no comparison of failure modes or retransmissions is given

This first example compares and contrasts a GET method to a resource containing an XML representation of a simple switch using HTTP/1.1 and HTTP/2.

Client sends (47 octets):

In ASCII:

Server sends (107 + 36 octets):

In ASCII:

\n \toff\n ]]>

Client sends (34 octets):

Representing:

Server sends (54 octets):

Representing:

Server sends (45 octets):

Representing:

\toff ]]>

In total and ignoring the payload (36 octets), the HTTP/2 flow is 37% smaller than the HTTP/1.1 flow. The use of additional headers, particularly common headers that are present in the HTTP/2 static table, will result in greater savings. While not compared here, HTTP/2's ability to reuse connections for multiple streams reduces connection establishment overhead, such as TCP connection establishment and TLS session establishment.

QUIC (Quick UDP Internet Connections) is a new multiplexed transport protocol designed to run in user space above UDP, optimized for HTTP/2 semantics. In this document, "QUIC" refers to the upcoming IETF standard. The protocol is still in its early days and the standardization work in IETF has just started. QUIC provides functionality already present in TCP and HTTP/2 connection semantics, reliability, and congestion control equivalent to TCP. multiplexing and flow control equivalent to HTTP/2 Where functionality is similar to that of existing protocols, it has been re-designed to be more efficient. For example, the native multistream provides multiplexing without the head-of-line blocking inherent to HTTP/2 over TCP. QUIC will use DTLS 1.3. Accordingly, connections will commonly benefit from 0-RTT as defined by TLS 1.3, meaning that on most QUIC connections, data can be sent immediately without waiting for a reply from the server. Furthermore, packets are always authenticated and typically the payload is fully encrypted. QUIC has been designed to provide richer information to congestion control algorithms than TCP, moreover the actual congestion control is plugable in QUIC. Even if QUIC has been initially designed with HTTP/2 as the primary application protocol to support, it is meant to become a modern general-purpose transport protocol. The IETF standardization effort will also focus on describing the mapping of HTTP/2 semantics using QUIC specifically with the goal of minimizing web latency using QUIC. This mapping will accommodate the extension mechanisms defined in the HTTP/2 specification. QUIC also dictates that packets should be sized to fit within the path's MTU to avoid IP fragmentation. However path MTU discovery is work in progress, and the current QUIC implementation uses a 1350-byte maximum QUIC packet size for IPv6, 1370 for IPv4. Judging from its current state, QUIC may bring some potential benefits like the possibility to design and use a specific congestion control algorithm suited to IoT scenarios and possibility to reduce header overhead as compared to that of TCP plus HTTP/2. The latter is possible since these two layers are more integrated in QUIC.

This document has no considerations for IANA.

and above point out security issues in the current IoT landscape, namely, the additional attack vectors from having several bespoke stacks instead of one mainstream stack and protocols. This document seeks to improve security of the IoT by encouraging use of mainstream protocols which are better understood and more thoroughly debugged (both in their specifications as well as in their implementations). point out another issue with the current IoT landscape: the proliferation of gateways and proxies. Whereas they serve useful functions in IoT, allowing more constrained nodes to have much lower duty cycles or filtering them from much traffic, there are inherent security issues, not the least of which is that they break end-to-end security. Enabling more mainstream protocols would not preclude using a proxy or gateway whenever the tradeoff dictated it, but would also allow for end-to-end security. Given the security challenges in IoT scenarios, HTTP/2 is assumed to use TLS services. In Internet scenarios, has clear guidance in this respect. In Constrained network scenarios, the guidance for IoT is . However, these are currently at odds. For example, Section 4.2 of mandates the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 for preshared key-based authentication (quite common in IoT deployments). On the other hand, Appendix A of includes TLS_PSK_WITH_AES_128_CCM_8 in the HTTP/2 Black List of disallowed cipher suites, despite it being an AEAD ciphersuite. This is still to be resolved. The other IoT ciphersuite mandated by , namely, TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (used for both certificate-based and Raw Public Key-based authentication) is not on the HTTP/2 Black List.

Thanks to the following individuals for helpful comments and discussion: Brian Raymor, Dave Thaler, Ed Briggs. This document was produced using the xml2rfc tool .