idnits 2.17.1 draft-montenegro-httpbis-h2ot-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 8, 2016) is 2848 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 826, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-02 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 7749 (Obsoleted by RFC 7991) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Montenegro 3 Internet-Draft Microsoft 4 Intended status: Informational S. Cespedes 5 Expires: January 9, 2017 Universidad de Chile 6 S. Loreto 7 Ericsson 8 R. Simpson 9 General Electric 10 July 8, 2016 12 H2oT: HTTP/2 for the Internet of Things 13 draft-montenegro-httpbis-h2ot-00 15 Abstract 17 This document makes the case for HTTP/2 for IoT. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 9, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Application Transport Alternatives and their Strengths . . . 4 55 2.1. HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.2. MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.4. Protocols Comparison . . . . . . . . . . . . . . . . . . 8 59 3. Importance of Protocol Reuse . . . . . . . . . . . . . . . . 8 60 4. HTTP/2 in IoT . . . . . . . . . . . . . . . . . . . . . . . . 10 61 5. Profile of HTTP/2 for IoT . . . . . . . . . . . . . . . . . . 11 62 6. Negotiation of HTTP/2 for IoT . . . . . . . . . . . . . . . . 12 63 7. Gateway and Proxying Issues . . . . . . . . . . . . . . . . . 12 64 8. Implementation Considerations . . . . . . . . . . . . . . . . 13 65 9. Experimentation and Performance . . . . . . . . . . . . . . . 13 66 9.1. GET Example . . . . . . . . . . . . . . . . . . . . . . . 14 67 9.1.1. HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . 14 68 9.1.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 15 69 9.1.3. Comparison . . . . . . . . . . . . . . . . . . . . . 16 70 10. HTTP/2 over UDP - QUIC . . . . . . . . . . . . . . . . . . . 16 71 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 72 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 76 14.2. Informative References . . . . . . . . . . . . . . . . . 19 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 79 1. Introduction 81 When the IETF started work on the Internet-of-Things ("IoT") with the 82 6lowpan WG, it was clear that in addition to the lower-layer 83 adaptation work for IPv6, much work elsewhere in the stack was 84 necessary. (In this document, the "things" in "IoT" are nodes that 85 are constrained in some manner--e.g., cpu, memory, power--such that 86 direct use of unmodified mainstream protocols is challenging.) Once 87 the IPv6 adaptation was understood, the next question was what 88 protocols to use above IP(v6) for different functions and at 89 different layers to have a complete stack. That question may not 90 have a single answer that is always best for all scenarios and use 91 cases. There are many such use cases, in accordance with the fact 92 that IoT means too many things. 94 Accordingly, the IoT landscape includes a proliferation of options 95 for any particular functionality (transport, encoding, security 96 suites, authentication/authorization, etc). Different vendors and 97 standards organizations (or fora) offer IoT solutions by grouping 98 these different components into separate stacks. Even if the 99 components have the same name or originate in the same original 100 standard (or even in the same code base), each organization adapts it 101 ever so slightly to their own goals, often rendering the resultant 102 components non-interoperable. Many of these components are being 103 created expressly for IoT (within the IETF and elsewhere) under the 104 assumption that the mainstream options could not possibly be usable 105 for IoT scenarios. This results in multiple disparate networking and 106 software stacks. Given the incipient state of IoT, for the 107 foreseeable future multiple competing stacks will continue to exist 108 at least in gateways and cloud elements. The additional complexity 109 to IoT amplifies the attack surface. Nevertheless, properly 110 configured and implemented, mainstream options may not just be 111 workable, but may even be the best option at least in some scenarios. 113 The appearance of one-off stacks (as opposed to a properly configured 114 and adapted mainstream stack) is reminiscent of WAP 1.x, a complete 115 vertical stack offered for phones as they were starting to access the 116 Internet (albeit from within a walled garden) in the late 90's. At 117 that time the IETF and the W3C started efforts to develop the 118 mainstream alternatives. As a result, today no phone uses WAP. 119 Instead, phone stacks are mainstream TCP/IP protocols (properly 120 configured and adapted, of course). In contrast, today in IoT we see 121 not just one non-mainstream stack, but several (as if we had not just 122 WAP, but WAP1, WAP2, WAP3, etc.). And we may have to live with them 123 for some time, but it is essential to ponder what the mainstream 124 stack might look like if we are to eventually reap the benefits of a 125 true Internet of Things instead of a not-quite-but-kinda-close-to- 126 Internet-non-interoperable-hodge-podge-of-Things. 128 HTTP/2 [RFC7540][RFC7541] is now widely available as a transport 129 option. Moreover, the ongoing effort to layer HTTP/2 over UDP (i.e., 130 over QUIC) adds a useful capability for IoT scenarios. We show the 131 current suitability of HTTP/2 for IoT scenarios and examine possible 132 improvements. 134 Let's look at some application communication patterns to establish 135 some common language (see also section 2 of [RFC7452] for a related 136 discussion): 138 node to node: A constrained node engages in direct communication 139 with another constrained node. 141 node to gateway: A constrained node and a gateway node engage in 142 direct communication. A gateway node is directly on both a 143 constrained network (e.g., a lowpan) and on a non-constrained 144 network (a normal network using mainstream stack implementations, 145 typically connected to the Internet). 147 gateway to cloud: A gateway node (see above) engages in 148 communication with unconstrained networks, typically a cloud 149 service on the Internet. 151 node to cloud: A node on a constrained network engages in direct 152 communcation with unconstrained networks, typically a cloud 153 service on the Internet. 155 In the above, a "node" may, in fact, be multiple nodes when engaging 156 in group communication. Group communications (e.g., via multicast) 157 are commonly used for discovery or routing (see also Section 2.3). 159 We can further categorize the above communication patterns into two 160 basic types of networking exchanges: 162 Constrained network scenario: A constrained network scenario 163 includes node to node and node to gateway exchanges. Group 164 communications are another typical aspect of these constrained 165 networks. 167 Internet scenario: An Internet scenario includes gateway to cloud 168 and node to cloud exchanges. 170 This document makes the case for HTTP/2 as the most general protocol 171 of choice for Internet of Things applications. HTTP/2 is most at 172 home in Internet scenarios and is also suitable for at least some 173 Constrained network scenarios. 175 2. Application Transport Alternatives and their Strengths 177 A recent survey by the Eclipse IoT working group queried IoT 178 developers about the protocols and technologies they are using and 179 planning to use [Eclipse_survey]. Some of the currently used 180 application transport protocols (above the link layer) for IoT 181 applications are as follows: 183 o HTTP/1.1 (61% of developers) 185 o MQTT (52% of developers) 187 o CoAP (21% of developers) 189 o HTTP/2 (19% of developers) 191 o Others: In-house, AMQP and XMPP (43% of developers) 192 It is interesting to note that in the same survey done in 2015, 193 HTTP/2 was not even present, whereas it is now at 19% (the other 194 protocols are mostly unchanged). No doubt it is being used in 195 scenarios where there are no major constraints (precisely where 196 HTTP/1.x is also being used). Optimizing it for IoT can further 197 promote its use. The sections below provide some more details on 198 top-of-the-list protocols other than HTTP/2. 200 2.1. HTTP/1.1 202 HTTP/1.1 is a text-based protocol, and is widely successful as it is 203 the basis not just for the web, but for much non-web traffic in the 204 internet today. Most (but not all) of the instances of HTTP today 205 implement version 1.1 as specified in RFC2616 [RFC2616]. Since its 206 publication back in 1999 it has evolved organically, producing 207 countless variations and exceptions to its rules. Modern browser and 208 server implementations have very complex and convoluted code to deal 209 with parsing and handling the many nuances of the protocol. Because 210 of all this confusion, the HTTPbis working group set out to clarify 211 the existing specifications, and after a multi-year effort to clarify 212 its many sources of confusion, it has published a cleaner 213 specification in RFCs 7230-7235 [RFC7230] [RFC7231] [RFC7232] 214 [RFC7233] [RFC7234] [RFC7235]. In spite of this, the protocol still 215 has a plethora of legacy issues and remains too verbose. 217 HTTP/1.1 is very clearly a mismatch for the constrained devices and 218 networks that characterize IoT. Despite its shortcomings, it is the 219 most popular protocol for IoT applications (61% per the 220 aforementioned survey, although the survey does not clarify if this 221 is for Internet or constrained network scenarios). Why would such an 222 ill-suited protocol be clearly the most popular for IoT applications? 223 It is by far the most commonly known protocol. It has many 224 implementations (many in open source), with massive support in all 225 platforms, tools and APIs. It is easy to find know-how and support. 226 In short, it has the power and convenience that comes with being a 227 mainstream protocol. 229 Another major advantage is that it is the protocol that has the best 230 chance of traversing firewalls and middle boxes in the internet due 231 to its use of port 80 when in the clear, and, especially, its use of 232 port 443 when over TLS. This is a primary concern in Internet 233 scenarios. 235 2.2. MQTT 237 MQ Telemetry Transport (MQTT) is a publish/subscribe messaging 238 protocol that runs on top of TCP. It was created by IBM. Version 239 3.1.1 is available as an OASIS standard [mqtt_oasis] and as an ISO 240 publication [mqtt_iso]. It is popular in the Internet scenario (node 241 to cloud, gateway to cloud) and it aims to connect embedded devices 242 and networks with applications and middleware. It is a compact, 243 binary protocol, and is very popular in certain application domains. 244 It has been known as a protocol suitable to be used in resource 245 constrained devices and unreliable networks. 247 It is the second most popular protocol in the survey (behind 248 HTTP/1.1) with 52% of developers using it. In the internet scenario, 249 however, TLS is probably required. This additional TLS overhead 250 renders all protocols slightly larger, so, e.g., MQTT loses some 251 relative size advantage. 253 The MQTT protocol requires an underlying transport that provides an 254 ordered, lossless, stream of bytes from the Client to Server and 255 Server to Client. It cannot be used over UDP. There is an 256 alternative (and not standardized) variant called MQTT-SN (previously 257 called MQTT-S) which can use UDP, Zigbee or other datagram 258 transports, but this is a substantially different protocol which has 259 been tailored to meet the needs of small, battery-powered sensors 260 connected by wireless sensor networks (WSNs), and relies upon a MQTT- 261 SN Gateway or forwarder for external communications. 263 MQTT is closely tied to PUBLISH/SUBSCRIBE operations and this is the 264 only mode of message transfer. This means that MQTT cannot be used 265 for "node to node" communications because a server is required (the 266 server forwards messages between publishers and subscribers, manages 267 subscriptions, and performs user authorization functions.) The 268 exclusive use of publish/subscribe operations can complicate some IoT 269 operations, such as request-response traffic, and transferring large 270 payloads (e.g. firmware updates). It is sometimes desirable to use a 271 different protocol (like HTTP) for transferring large payloads, even 272 though MQTT supports a maximum per-message payload size of 256 MiB. 273 The OASIS MQTT-TC is considering proposals involving changes in 274 handling request-response traffic and large message transfers. 276 MQTT is deployed over TCP (port 8833 when over TLS, port 1883 without 277 TLS). Even when using TLS, it has the well-known firewall traversal 278 issues common to any protocol not over port 443. 280 2.3. CoAP 282 CoAP is a compact, binary, UDP-based protocol based on RESTful 283 principles and closely patterned after HTTP. It has been designed to 284 be used in constrained devices and constrained networks. The 285 protocol specification has been published [RFC7252], although 286 additional functionalities such as congestion control, block-wise 287 transfer, TCP and TLS transfer and HTTP mapping are still being 288 specified. 290 The protocol meets IoT requirements through the modification of some 291 HTTP functionalities to achieve low-power consumption and operation 292 over lossy links. To avoid undesirable packet fragmentation the CoAP 293 specification provides an upper bound to the message size, dictating 294 that a CoAP message, appropriately encapsulated, SHOULD fit within a 295 single IP datagram: 297 If the Path MTU is not known for a destination, an IP MTU of 1280 298 bytes SHOULD be assumed; if nothing is known about the size of the 299 headers, good upper bounds are 1152 bytes for the message size and 300 1024 bytes for the payload size. 302 CoAP interaction with HTTP must traverse a proxy, with the 303 concomitant issues of breaking end-to-end security (Section 7), but 304 at least the common REST architecture makes it easier. 306 CoAP works on port 5683 and offers optional reliable delivery (thru a 307 retransmission mechanism), support for unicast and multicast, and 308 asynchronous message exchange. Multicast (see Section 1 is typically 309 used by IoT SDO's for routing and discovery. A common use of 310 multicast within CoAP is for discovery, something addressed in 311 mainstream (and even some IoT) scenarios via mDNS [RFC6762] and DNS- 312 SD [RFC6763]. More general uses of multicast within CoAP (and, in 313 general, at the application transport, e.g., to address group 314 communication for IoT), introduces complexity for security, IPv6 315 scoping, wireless reliability, etc. 317 A typical CoAP message can be between 10 and 20 bytes. 319 It is the third most popular protocol in the survey with a 21% 320 preference. Nevertheless, since CoAP is UDP-based, in the Internet 321 scenario it also suffers from firewall traversal issues, verbosity 322 (as compared to TCP) to maintain state in NAT boxes and lack of 323 integration with existing enterprise infrastructures. There is 324 ongoing work to specify the use of CoAP over TCP as well as CoAP over 325 TLS, in an attempt to overcome issues with middleboxes and improve 326 its applicability to Internet scenarios. 328 As noted above, there is much ongoing work on CoAP, and much of it 329 seeks to define a transport on top of UDP. This is a very complex 330 task not to be underestimated. QUIC is also embarking on this task, 331 but it appears to be benefitting from many more resources within the 332 networking community at large. 334 2.4. Protocols Comparison 336 The aformentioned protocols have been compared in both experimental 337 and emulated environments [IEEE_survey]. Previous reports show that 338 performance is highly dependent on the network conditions: in good 339 link conditions with low packet loss, MQTT delivers packets with 340 lower delay than CoAP, but CoAP outperforms when high packet losses 341 are present; in terms of packet sizes, if packet loss is under 25% 342 and messages are of a small size, CoAP demonstrates a better link 343 usage than MQTT. However, other experiments report a better 344 performance of MQTT in high traffic/high packet loss scenarios 345 [IoT_analysis]. CoAP has also been compared to HTTP/1.1. In terms 346 of power consumption and response time, naturally CoAP behaves better 347 than HTTP/1.1 thanks to the reduced packet sizes. 349 Coexistence among the protocols has also been tested with varied 350 network configurations. For the most part, interaction of CoAP with 351 HTTP has been studied [Web_things], demonstrating successful exchange 352 when there is a CoAP server running on a constrained node and the 353 HTTP client is requesting resources from it, or when there is a CoAP 354 client requesting resources from an HTTP server. In both cases a 355 proxy is necessary to enable translation between the protocols. 356 Another network configuration with a CoAP client - CoAP proxy - CoAP 357 server has been compared to the CoAP client - CoAP/HTTP proxy - HTTP 358 server configuration, in which case the response times of the only- 359 CoAP configuration resulted to be lower even when the number of 360 concurrent requests increases [CoAP_integration]. 362 To date, no reports have been found comparing MQTT or CoAP to HTTP/2. 364 3. Importance of Protocol Reuse 366 These protocols often do not exist in a vacuum. Typically, they are 367 mandated as part of a given stack specified by any of several IoT 368 consortia (e.g., OCF, AllSeen Alliance/AllJoyn, Thread Group). We 369 know that these multiple IoT protocols (and stacks) provide very 370 useful sources of information for prying eyes (See "US intelligence 371 chief says we might use the IoT to spy on you" at 372 http://www.wired.com/2012/03/petraeus-tv-remote/). Security and 373 privacy issues are exacerbated because: 375 o IoT is the worst of all security worlds: (1) constraints push 376 devices into taking shortcuts and (2) there is less physical 377 security with such devices (after installation they are typically 378 reachable by unfriendly hands). 380 o Each of these protocols is an island with its own security 381 measures (or lack thereof) and very limited review. 383 The previous two points can be summarized as follows: 385 A security and privacy environment even more challenging than usual: 387 This is receiving much attention from the research and 388 standardization communities. It is the sort of challenge that 389 stimulates researchers into high gear. It is a daunting problem 390 for sure, but at least it is on the radar of folks and consortia 391 working on IoT. Nevertheless, many issues will arise because of 392 this (e.g., discovery of serious flaws in IoT devices like locks 393 is a common occurrence). 395 Many different protocol stacks at play: This is a much more 396 worrisome issue if one considers that a vast majority of issues 397 arising with security have less to do with cryptography (the first 398 point above) and more to do with software engineering, and silly 399 bugs. Each stack added creates more attack surface. At the same 400 time, each one of these stacks gather less attention and scrutiny 401 than software used for mainstream scenarios (such as the web). We 402 have seen no shortage of issues on OpenSSL and similar heavily- 403 used software. We can expect much worse from stacks that are not 404 nearly as well exercised nor examined. And if we have not one, 405 but several of these stacks untested by millions of eyeballs, we 406 are inviting disaster. 408 A recent Harvard report on the state of surveillance and erosion of 409 privacy [Going_Dark] concludes among its findings that the projected 410 substantial growth of IoT will drastically change surveillance 411 (surveillance is not merely limited to government agencies of 412 course), and that the fragmentation of ecosystems hinders the 413 deployment of countermeasures (e.g., end-to-end encryption) as that 414 requires more coordination and standardization than currently 415 available. This not only gives rise to rogue surveillance sites such 416 as Shodan (https://www.shodan.io/), but also represents a great 417 opportunity for government agencies' surveillance needs [Clapper]. 419 Furthermore, multiple stacks defeat one of the main benefits of the 420 "I" in IoT: interoperability. Also, reusing mainstream protocols 421 affords the benefits of using better-known technology, with easier 422 access to reference implementations (including open source), people 423 with the required skills and experience, training, etc. These are 424 basically the same arguments that were used originally to justify the 425 use of IP-based networking over custom-built stacks. The message was 426 heard loud and clear but for the most part it was applied to only a 427 limited set of components (e.g., IP, UDP, DTLS). Other components 428 are still being custom built (albeit, on top of IP). 430 4. HTTP/2 in IoT 432 As noted above, for the foreseeable future the IoT landscape requires 433 several stacks. Thinking about a canonical stack based on mainstream 434 protocols is not an exercise in the delusion that one single stack 435 will be enough. Rather, it is an attempt to define an option that 436 can serve IoT better into the future, and one that can be recommended 437 whenever there is a choice (often there isn't one). 439 The goals in pursuing a canonical stack are the following: 441 o Maximize Standards-based Elements across technologies and IoT 442 stacks 444 o Reduce IoT protocol idiosyncrasies and specificity 446 o Reduce the number of "translators" needed in an IoT hub 448 To arrive at a canonical stack the mainstream standards-based stack 449 must be properly profiled and optimized. This requires optimizing 450 aspects such as: 452 o Authentication and Authorization framework by adapting OAUTH 453 instead of inventing a new system [I-D.ietf-ace-oauth-authz]. 455 o Device Management and Object Model/Descriptions (currently being 456 defined). 458 o Discovery via mDNS [RFC6762] and DNS-SD [RFC6763] perhaps 459 augmented with IoT considerations, e.g., 460 [I-D.aggarwal-dnssd-optimize-query]. Another option to 461 investigate is that of HTTP/2 over multicast. Whereas there have 462 been some forays into HTTP over multicast, it is not nearly as 463 well deployed, implemented and understood as mDNS. 465 o Application Transport based on HTTP/2. 467 This document deals only with the application layer transport based 468 on HTTP/2. 470 HTTP/2 is a good match for IoT for several reasons: 472 o Binary and Compact (9 byte header) 474 o Header Compression [RFC7541] 476 o Traversal past firewalls/middle boxes via TLS over port 443 477 o Support of RESTful model in major development frameworks 479 o Know-how widely available 481 5. Profile of HTTP/2 for IoT 483 HTTP/2 has many negotiable settings that can improve its performance 484 for IoT applications by reducing bandwidth, codespace, and RAM 485 requirements. Specifically, the following settings and values have 486 been found to be useful in IoT applications: 488 o SETTINGS_HEADER_TABLE_SIZE: this setting allows hosts to limit the 489 size of the header compression table used for decoding, reducing 490 required RAM, but potentially increasing bandwidth requirements. 491 Initial value per HTTP/2 is 4096. IoT scenarios might benefit 492 from changing this to a smaller value (e.g., 512), however, to 493 avoid increased bandwidth usage, IoT scenarios should judiciously 494 use HTTP headers and the dynamic header table [RFC7541]. 496 o SETTINGS_ENABLE_PUSH: This setting allows clients to enable or 497 disable server push. This functionality may not be required in 498 some IoT applications. The initial value per HTTP/2 is 1. 500 o SETTINGS_MAX_CONCURRENT_STREAMS: this setting allows a sender to 501 limit the number of simultaneous streams that a receiver can 502 create for a connection. HTTP/2 recommends this value be no 503 smaller than 100. IoT scenarios may wish to limit this to a much 504 smaller number, such as 2 or 3. 506 o SETTINGS_INITIAL_WINDOW_SIZE: this setting allows hosts to limit 507 the flow control window, potentially reducing buffer requirements 508 at the expense of potentially underutilized bandwidth-delay 509 products. Per HTTP/2 the initial value is 2^16-1 (65,535) octets. 510 IoT scenarios may wish to limit this to smaller values in 511 accordance with the node's constraints (e.g., a few kilo-octets). 513 o SETTINGS_MAX_FRAME_SIZE: this setting allows hosts to specify the 514 largest frame size they are willing to receive. Per HTTP/2 the 515 initial value is 2^14 (16,384) octets. Somewhat 516 counterintuitively, IoT hosts may wish to leave this value large 517 and rely on flow control to avoid unnecessary framing overhead. 519 o SETTINGS_MAX_HEADER_LIST_SIZE: this setting allows hosts to limit 520 the maximum size of the header list they are willing to receive. 521 Per HTTP/2 the initial value of this setting is unlimited. IoT 522 scenarios may wish to limit this to smaller values in accordance 523 with the node's constraints (e.g., a few kilo-octets). 525 6. Negotiation of HTTP/2 for IoT 527 For Constrained and Internet scenarios, it is assumed that HTTP/2 528 runs over TLS. Accordingly, the ALPN negotiation in section 3.3 of 529 [RFC7540] applies. As seen above, an IoT scenario may wish to depart 530 from the default SETTINGS. To do so, the usual SETTINGS negotiation 531 applies. In this case, the initial SETTINGS negotiation setup is 532 based on the first message exchange initiated by the client. This is 533 simpler than general HTTP/2 case: not having an in-the-clear Upgrade 534 path means the client is always in control of first HTTP/2 message, 535 including any SETTINGS changes it may wish. 537 Additionally, the use of "prior knowledge" per section 3.4 of 538 [RFC7540] is likely to also work particularly well in IoT scenarios 539 in which a client and its web service are likely to be closely 540 matched. In such scenarios, prior knowledge may allow for SETTINGS 541 to be set in accordance with some shared state implied by the the 542 prior knowledge. In such cases, SETTINGS negotiation may not be 543 necessary in order to depart from the defaults as defined by HTTP/2. 545 7. Gateway and Proxying Issues 547 The proliferation of application and security protocols in the IoT 548 has produced the deployments of islands of IoT devices, each using 549 one of the several protocols available. However, usually an IoT 550 deployment needs to communicate to another one, or at least needs to 551 communicate with the Web, both because they have to upload data to 552 the Cloud or because usually they are controlled by a Web 553 application. 555 In such cases, communication is facilitated by a cross-protocol proxy 556 or a gateway translating from one protocol syntax and semantic into 557 another one. However, the presence of Cross-Protocol or Application 558 gateways has at least two main drawbacks that need to be analyzed and 559 addressed carefully. 561 o while the translation may be trivial for the basic scenarios, 562 there are a lot of cases where the translation can lead to 563 information loss or an incompatibility due to the different way 564 different proxies make the translation. 566 o The presence of such devices may also become a critical point for 567 security. 569 8. Implementation Considerations 571 This section assumes HTTP/2 over TCP. 573 In addition to underlying stack considerations with respect to IPv4, 574 IPv6, TCP, and TLS, there are implementation considerations for 575 HTTP/2 for IoT. 577 A primary consideration is the number of allowed simultaneous HTTP/2 578 connections. As each connection has associated overhead, as well as 579 overhead for each stream, constrained hosts may wish to limit their 580 number of simultaneous connections. However, implementers should 581 consider that some popular browsers require more than one connection 582 to operate. 584 In addition to minimizing the number of simultaneous connections, 585 hosts should consider leaving connections open if there is a 586 possibility of further communication with the remote peer. HTTP/2 587 contains mechanisms such as PING to periodically check idle 588 connections. Leaving established connections open when there is a 589 possibility of future communication allows connection establishment 590 overhead (and potentially TLS session establishment overhead) to be 591 avoided. 593 Should TLS be used, implementers may wish to consider utilizing 594 hardware-based encryption to further reduce codespace and RAM 595 requirements. 597 9. Experimentation and Performance 599 This section presents some simple results obtained using the 600 Deuterium HTTP/2 library [Deuterium] and is not intended to be 601 complete, but rather a start for discussion. From an IoT 602 perspective, the reduced message sizes presented help to conserve 603 both bandwidth and battery life, as well as potentially saving some 604 memory/buffer space. 606 The results presented in this section make the following assumptions 607 and considerations: 609 o Overhead from TCP and TLS are ignored 611 o An attempt to minimize the headers used has been made while still 612 maintaining RFC compliance 614 o No entries are made into the HTTP/2 dynamic table, thus removing 615 some potential optimization 617 o Connection establishment and teardown have been ignored, though 618 clearly these are important considerations for IoT application 619 protocols 621 o Only happy path transmissions are shown, thus no comparison of 622 failure modes or retransmissions is given 624 9.1. GET Example 626 This first example compares and contrasts a GET method to a resource 627 containing an XML representation of a simple switch using HTTP/1.1 628 and HTTP/2. 630 9.1.1. HTTP/1.1 632 1. Client sends (47 octets): 634 4745 5420 2f6f 6e6f 6666 2048 5454 502f 312e 310d 635 0a48 6f73 743a 2066 6f6f 0d0a 4163 6365 7074 3a20 636 2a2f 2a0d 0a0d 0a 638 In ASCII: 640 GET /onoff HTTP/1.1\r\n 641 Host: foo\r\n 642 Accept: */*\r\n 643 \r\n 645 2. Server sends (107 + 36 octets): 647 4854 5450 2f31 2e31 2032 3030 204f 4b0d 0a44 6174 648 653a 204d 6f6e 2c20 3039 204d 6172 2032 3031 3520 649 3036 3a32 363a 3434 2047 4d54 0d0a 436f 6e74 656e 650 742d 4c65 6e67 7468 3a20 3336 0d0a 436f 6e74 656e 651 742d 5479 7065 3a20 6170 706c 6963 6174 696f 6e2f 652 786d 6c0d 0a0d 0a 653 3c4f 6e4f 6666 3e0a 093c 7374 6174 653e 6f66 663c 654 2f73 7461 7465 3e0a 3c2f 4f6e 4f66 663e 656 In ASCII: 658 HTTP/1.1 200 OK\r\n 659 Date: Mon, 09 Mar 2015 06:26:44 GMT\r\n 660 Content-Length: 36\r\n 661 Content-Type: application/xml\r\n 662 \r\n 663 \n 664 \toff\n 665 667 9.1.2. HTTP/2 669 1. Client sends (34 octets): 671 0000 1901 0500 0000 01 672 8286 0585 60f5 1e59 7f01 8294 e70f 0489 f963 e7ef 673 b401 5c00 07 675 Representing: 677 :method: GET 678 :path: /onoff 679 :scheme: http 680 :authority: foo 681 accept: */* 683 2. Server sends (54 octets): 685 0000 2d01 0400 0000 01 686 880f 1296 d07a be94 03ea 681d 8a08 016d 4039 704e 687 5c69 a531 68df 0f10 8b1d 75d0 620d 263d 4c79 a68f 688 0f0d 8265 cf 690 Representing: 692 :status: 200 693 content-type: application/xml 694 content-length: 36 695 date: Mon, 09 Mar 2015 06:26:44 GMT 697 3. Server sends (45 octets): 699 0000 2400 0100 0000 01 700 3c4f 6e4f 6666 3e0a 093c 7374 6174 653e 6f66 663c 701 2f73 7461 7465 3e0a 3c2f 4f6e 4f66 663e 703 Representing: 705 706 \toff 707 709 9.1.3. Comparison 711 In total and ignoring the payload (36 octets), the HTTP/2 flow is 37% 712 smaller than the HTTP/1.1 flow. 714 The use of additional headers, particularly common headers that are 715 present in the HTTP/2 static table, will result in greater savings. 717 While not compared here, HTTP/2's ability to reuse connections for 718 multiple streams reduces connection establishment overhead, such as 719 TCP connection establishment and TLS session establishment. 721 10. HTTP/2 over UDP - QUIC 723 QUIC (Quick UDP Internet Connections) is a new multiplexed transport 724 protocol designed to run in user space above UDP, optimized for 725 HTTP/2 semantics. In this document, "QUIC" refers to the upcoming 726 IETF standard. The protocol is still in its early days and the 727 standardization work in IETF has just started. 729 QUIC provides functionality already present in TCP and HTTP/2 731 o connection semantics, reliability, and congestion control 732 equivalent to TCP. 734 o multiplexing and flow control equivalent to HTTP/2 736 Where functionality is similar to that of existing protocols, it has 737 been re-designed to be more efficient. For example, the native 738 multistream provides multiplexing without the head-of-line blocking 739 inherent to HTTP/2 over TCP. 741 QUIC will use DTLS 1.3. Accordingly, connections will commonly 742 benefit from 0-RTT as defined by TLS 1.3, meaning that on most QUIC 743 connections, data can be sent immediately without waiting for a reply 744 from the server. Furthermore, packets are always authenticated and 745 typically the payload is fully encrypted. 747 QUIC has been designed to provide richer information to congestion 748 control algorithms than TCP, moreover the actual congestion control 749 is plugable in QUIC. 751 Even if QUIC has been initially designed with HTTP/2 as the primary 752 application protocol to support, it is meant to become a modern 753 general-purpose transport protocol. The IETF standardization effort 754 will also focus on describing the mapping of HTTP/2 semantics using 755 QUIC specifically with the goal of minimizing web latency using QUIC. 756 This mapping will accommodate the extension mechanisms defined in the 757 HTTP/2 specification. 759 QUIC also dictates that packets should be sized to fit within the 760 path's MTU to avoid IP fragmentation. However path MTU discovery is 761 work in progress, and the current QUIC implementation uses a 762 1350-byte maximum QUIC packet size for IPv6, 1370 for IPv4. 764 Judging from its current state, QUIC may bring some potential 765 benefits like the possibility to design and use a specific congestion 766 control algorithm suited to IoT scenarios and possibility to reduce 767 header overhead as compared to that of TCP plus HTTP/2. The latter 768 is possible since these two layers are more integrated in QUIC. 770 11. IANA Considerations 772 This document has no considerations for IANA. 774 12. Security Considerations 776 Section 1 and Section 3 above point out security issues in the 777 current IoT landscape, namely, the additional attack vectors from 778 having several bespoke stacks instead of one mainstream stack and 779 protocols. This document seeks to improve security of the IoT by 780 encouraging use of mainstream protocols which are better understood 781 and more thoroughly debugged (both in their specifications as well as 782 in their implementations). 784 Section 7 point out another issue with the current IoT landscape: the 785 proliferation of gateways and proxies. Whereas they serve useful 786 functions in IoT, allowing more constrained nodes to have much lower 787 duty cycles or filtering them from much traffic, there are inherent 788 security issues, not the least of which is that they break end-to-end 789 security. Enabling more mainstream protocols would not preclude 790 using a proxy or gateway whenever the tradeoff dictated it, but would 791 also allow for end-to-end security. 793 Given the security challenges in IoT scenarios, HTTP/2 is assumed to 794 use TLS services. In Internet scenarios, [RFC7540] has clear 795 guidance in this respect. In Constrained network scenarios, the 796 guidance for IoT is [I-D.ietf-dice-profile]. However, these are 797 currently at odds. For example, Section 4.2 of 798 [I-D.ietf-dice-profile] mandates the ciphersuite 799 TLS_PSK_WITH_AES_128_CCM_8 for preshared key-based authentication 800 (quite common in IoT deployments). On the other hand, Appendix A of 802 [RFC7540] includes TLS_PSK_WITH_AES_128_CCM_8 in the HTTP/2 Black 803 List of disallowed cipher suites, despite it being an AEAD 804 ciphersuite. This is still to be resolved. The other IoT 805 ciphersuite mandated by [I-D.ietf-dice-profile], namely, 806 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (used for both certificate-based 807 and Raw Public Key-based authentication) is not on the HTTP/2 Black 808 List. 810 13. Acknowledgements 812 Thanks to the following individuals for helpful comments and 813 discussion: Brian Raymor, Dave Thaler, Ed Briggs. 815 This document was produced using the xml2rfc tool [RFC2629][RFC7749]. 817 14. References 819 14.1. Normative References 821 [I-D.ietf-dice-profile] 822 Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles for the 823 Internet of Things", draft-ietf-dice-profile-17 (work in 824 progress), October 2015. 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, 828 DOI 10.17487/RFC2119, March 1997, 829 . 831 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 832 Protocol (HTTP/1.1): Message Syntax and Routing", 833 RFC 7230, DOI 10.17487/RFC7230, June 2014, 834 . 836 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 837 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 838 DOI 10.17487/RFC7231, June 2014, 839 . 841 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 842 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 843 DOI 10.17487/RFC7232, June 2014, 844 . 846 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 847 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 848 RFC 7233, DOI 10.17487/RFC7233, June 2014, 849 . 851 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 852 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 853 RFC 7234, DOI 10.17487/RFC7234, June 2014, 854 . 856 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 857 Protocol (HTTP/1.1): Authentication", RFC 7235, 858 DOI 10.17487/RFC7235, June 2014, 859 . 861 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 862 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 863 DOI 10.17487/RFC7540, May 2015, 864 . 866 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 867 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 868 . 870 14.2. Informative References 872 [Clapper] "US intelligence chief: we might use the internet of 873 things to spy on you", February 2016, 874 . 878 [CoAP_integration] 879 Giang, N., Ha, M., and D. Kim, "SCoAP: An integration of 880 CoAP protocol with web-based application", Proc. IEEE 881 GLOBECOM , 2013. 883 [Deuterium] 884 Simpson, R., "Deuterium HTTP/2 Library", June 2016, 885 . 887 [Eclipse_survey] 888 Eclipse Foundation, "IoT Developer Survey", April 2016, 889 . 892 [Going_Dark] 893 "Dont Panic: Making Progress on Going Dark Debate", 894 February 2016, . 898 [I-D.aggarwal-dnssd-optimize-query] 899 Aggarwal, A., "Optimizing DNS-SD query using TXT records", 900 draft-aggarwal-dnssd-optimize-query-00 (work in progress), 901 July 2014. 903 [I-D.ietf-ace-oauth-authz] 904 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 905 H. Tschofenig, "Authentication and Authorization for 906 Constrained Environments (ACE)", draft-ietf-ace-oauth- 907 authz-02 (work in progress), June 2016. 909 [IEEE_survey] 910 Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M., 911 and M. Ayyash, "Internet of Things: A Survey on Enabling 912 Technologies, Protocols, and Applications", IEEE 913 Communication Surveys and Tutorials , November 2015. 915 [IoT_analysis] 916 Colina, M., Bartolucci, M., Vanelli-Coralli, A., and G. 917 Corazza, "Internet of Things application layer protocol 918 analysis over error and delay prone links", Proc. ASMS/ 919 SPSC Conference , 2014. 921 [mqtt_iso] 922 ISO, "ISO/IEC 20922:2016 Information technology -- Message 923 Queuing Telemetry Transport (MQTT) v3.1.1", June 2016, 924 . 927 [mqtt_oasis] 928 OASIS, "MQTT Version 3.1.1 becomes an OASIS Standard", 929 October 2014, . 933 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 934 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 935 Transfer Protocol -- HTTP/1.1", RFC 2616, 936 DOI 10.17487/RFC2616, June 1999, 937 . 939 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 940 DOI 10.17487/RFC2629, June 1999, 941 . 943 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 944 DOI 10.17487/RFC6762, February 2013, 945 . 947 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 948 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 949 . 951 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 952 Application Protocol (CoAP)", RFC 7252, 953 DOI 10.17487/RFC7252, June 2014, 954 . 956 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 957 "Architectural Considerations in Smart Object Networking", 958 RFC 7452, DOI 10.17487/RFC7452, March 2015, 959 . 961 [RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", 962 RFC 7749, DOI 10.17487/RFC7749, February 2016, 963 . 965 [Web_things] 966 Lerche, C., Laum, N., Golatowski, F., Timmermann, D., and 967 C. Niedermier, "Connecting the web with the web of things: 968 lessons learned from implementing a CoAP-HTTP proxy", 969 Proc. IEEE MASS , 2012. 971 Authors' Addresses 973 Gabriel Montenegro 974 Microsoft 976 Email: Gabriel.Montenegro@microsoft.com 978 Sandra Cespedes 979 NIC Chile Research Labs, Universidad de Chile 981 Email: scespedes@ing.uchile.cl 983 Salvatore Loreto 984 Ericsson 986 Email: salvatore.loreto@ericsson.com 988 Robby Simpson 989 General Electric 991 Email: rsimpson@gmail.com