idnits 2.17.1 draft-montenegro-httpbis-h2ot-profile-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 date (March 10, 2017) is 2597 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- 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: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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: September 11, 2017 NIC Labs Chile 6 S. Loreto 7 Ericsson 8 R. Simpson 9 General Electric 10 March 10, 2017 12 HTTP/2 Configuration Profile for the Internet of Things 13 draft-montenegro-httpbis-h2ot-profile-00 15 Abstract 17 This document define an HTTP/2 configuration profile 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 September 11, 2017. 36 Copyright Notice 38 Copyright (c) 2017 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. Configuration Profile of HTTP/2 for IoT . . . . . . . . . . . 2 55 3. Negotiation of HTTP/2 for IoT . . . . . . . . . . . . . . . . 3 56 4. Implementation Considerations . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 8.2. Informative References . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 Unlike HTTP/1.X, HTTP/2 is suitable for many IoT applications. Even 68 though IoT was not the primary scenario when HTTP/2 was designed, the 69 protocol is compact, configurable and flexible. The use of header 70 compression as well as the binary encoding of the protocol reduces 71 the size of HTTP/2 flows as compared to HTTP/1.1. HTTP/2's ability 72 to reuse connections for multiple streams reduces connection 73 establishment overhead, such as TCP connection establishment and TLS 74 session establishment. HTTP/2 has been found to be amenable to 75 implementation on class 2 devices, per the constrained device 76 classification in section 3 of [RFC7228]. Furthermore, initial 77 efforts have resulted in successful experiments on class 1 devices. 79 This document discusses how to configure HTTP/2 so as to adapt it 80 better to IoT scenarios, including those in which the devices running 81 the protocol have constrained resources. 83 2. Configuration Profile of HTTP/2 for IoT 85 HTTP/2 has many negotiable settings that can improve its performance 86 for IoT applications by reducing bandwidth, codespace, and RAM 87 requirements. Specifically, the following settings and values have 88 been found to be useful in IoT applications: 90 o SETTINGS_HEADER_TABLE_SIZE: this setting allows hosts to limit the 91 size of the header compression table used for decoding, reducing 92 required RAM, but potentially increasing bandwidth requirements. 93 Initial value per HTTP/2 is 4096. IoT scenarios might benefit 94 from changing this to a smaller value (e.g., 512), however, to 95 avoid increased bandwidth usage, IoT scenarios should judiciously 96 use HTTP headers and the dynamic header table [RFC7541]. 98 o SETTINGS_ENABLE_PUSH: This setting allows clients to enable or 99 disable server push. This functionality may not be required in 100 some IoT applications. The initial value per HTTP/2 is 1. 102 o SETTINGS_MAX_CONCURRENT_STREAMS: this setting allows a sender to 103 limit the number of simultaneous streams that a receiver can 104 create for a connection. HTTP/2 recommends this value be no 105 smaller than 100. IoT scenarios may wish to limit this to a much 106 smaller number, such as 2 or 3. 108 o SETTINGS_INITIAL_WINDOW_SIZE: this setting allows hosts to limit 109 the flow control window, potentially reducing buffer requirements 110 at the expense of potentially underutilized bandwidth-delay 111 products. Per HTTP/2 the initial value is 2^16-1 (65,535) octets. 112 IoT scenarios may wish to limit this to smaller values in 113 accordance with the node's constraints (e.g., a few kilo-octets). 115 o SETTINGS_MAX_FRAME_SIZE: this setting allows hosts to specify the 116 largest frame size they are willing to receive. Per HTTP/2 the 117 initial value is 2^14 (16,384) octets. Somewhat 118 counterintuitively, IoT hosts may wish to leave this value large 119 and rely on flow control to avoid unnecessary framing overhead 120 (see: ). 123 o SETTINGS_MAX_HEADER_LIST_SIZE: this setting allows hosts to limit 124 the maximum size of the header list they are willing to receive. 125 Per HTTP/2 the initial value of this setting is unlimited. IoT 126 scenarios may wish to limit this to smaller values in accordance 127 with the node's constraints (e.g., a few kilo-octets). 129 3. Negotiation of HTTP/2 for IoT 131 For Constrained and Internet scenarios, it is assumed that HTTP/2 132 runs over TLS. Accordingly, the ALPN negotiation in section 3.3 of 133 [RFC7540] applies. As seen above, an IoT scenario may wish to depart 134 from the default SETTINGS. To do so, the usual SETTINGS negotiation 135 applies. In this case, the initial SETTINGS negotiation setup is 136 based on the first message exchange initiated by the client. This is 137 simpler than general HTTP/2 case: not having an in-the-clear Upgrade 138 path means the client is always in control of first HTTP/2 message, 139 including any SETTINGS changes it may wish. 141 Additionally, the use of "prior knowledge" per section 3.4 of 142 [RFC7540] is likely to also work particularly well in IoT scenarios 143 in which a client and its web service are likely to be closely 144 matched. In such scenarios, prior knowledge may allow for SETTINGS 145 to be set in accordance with some shared state implied by the prior 146 knowledge. In such cases, SETTINGS negotiation may not be necessary 147 in order to depart from the defaults as defined by HTTP/2. 149 4. Implementation Considerations 151 This section assumes HTTP/2 over TCP, i.e., as specified in 152 [RFC7540]. Implementors should consider TCP optimizations for IoT, 153 such as [I-D.gomez-core-tcp-constrained-node-networks] as well as 154 LoWPAN-related TCP optimizations such as [I-D.aayadi-6lowpan-tcphc]. 156 In addition to underlying stack issues with respect to IPv4, IPv6, 157 TCP, and TLS, there are implementation considerations for HTTP/2 for 158 IoT. 160 A primary concern is the number of allowed simultaneous HTTP/2 161 connections. As each connection has associated overhead, as well as 162 overhead for each of its streams, constrained hosts may wish to limit 163 their number of simultaneous connections. However, implementers 164 should note that some popular browsers require more than one 165 connection to operate (e.g., both Chrome and Firefox have been 166 observed as requiring at least two connections). Given that one of 167 the motivations to use HTTP/2 is to use mainstream technologies, this 168 is important for certain scenarios. 170 In addition to minimizing the number of simultaneous connections, 171 hosts should consider leaving connections open if there is a 172 possibility of further communication with the remote peer. HTTP/2 173 contains mechanisms such as PING to periodically check idle 174 connections. Leaving established connections open when there is a 175 possibility of future communication allows connection establishment 176 overhead (and potentially TLS session establishment overhead) to be 177 avoided. 179 Should TLS be used, implementers may wish to utilize hardware-based 180 encryption to further reduce codespace and RAM requirements. 182 5. IANA Considerations 184 This document has no considerations for IANA. 186 6. Security Considerations 188 This document suggests a profile for HTTP/2 in IoT applications. All 189 the security considerations for [RFC7540] apply. Given the 190 constraints likely to characterize devices common in IoT scenarios, 191 issues related to resource exhaustion and denial-of-service attacks 192 are particularly noteworthy. Nevertheless, the suggestions in this 193 document limit the resources used in such a way that any peer 194 exceeding such limits will be in protocol violation making those 195 connection or connection attempts readily droppable. Of course, 196 resource exhaustion attacks are not mitigated, as these will simply 197 obey the limits imposed by the constrained profile specified herein. 198 Hence, it is always imperative to safeguard IoT devices by the usual 199 means (e.g., by using a firewall or a gateway with richer resources 200 to provide some protection). 202 As for the potential risks to the infrastructure by attacks launched 203 from devices compliant with this specification, each such instance 204 represents less of a threat than usually configured and profiled 205 HTTP/2 clients. Nevertheless, the sheer number of IoT devices means 206 that the overall threat to infrastructure may be formidable, as has 207 been observed in IoT-based DDoS attacks. Accordingly, it is 208 essential for these devices to implement the usual security measures 209 to prevent their hijacking by e.g., requiring strong authentication 210 of the operators, update capabilities, etc. 212 7. Acknowledgements 214 This document was produced using the xml2rfc tool [RFC2629][RFC7749]. 216 8. References 218 8.1. Normative References 220 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 221 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 222 DOI 10.17487/RFC7540, May 2015, 223 . 225 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 226 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 227 . 229 8.2. Informative References 231 [I-D.aayadi-6lowpan-tcphc] 232 Ayadi, A., Ros, D., and L. Toutain, "TCP header 233 compression for 6LoWPAN", draft-aayadi-6lowpan-tcphc-01 234 (work in progress), October 2010. 236 [I-D.gomez-core-tcp-constrained-node-networks] 237 Gomez, C. and J. Crowcroft, "TCP over Constrained-Node 238 Networks", draft-gomez-core-tcp-constrained-node- 239 networks-00 (work in progress), June 2016. 241 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 242 DOI 10.17487/RFC2629, June 1999, 243 . 245 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 246 Constrained-Node Networks", RFC 7228, 247 DOI 10.17487/RFC7228, May 2014, 248 . 250 [RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", 251 RFC 7749, DOI 10.17487/RFC7749, February 2016, 252 . 254 Authors' Addresses 256 Gabriel Montenegro 257 Microsoft 259 Email: Gabriel.Montenegro@microsoft.com 261 Sandra Cespedes 262 NIC Labs Chile 263 Universidad de Chile 265 Email: scespedes@ing.uchile.cl 267 Salvatore Loreto 268 Ericsson 270 Email: salvatore.loreto@ericsson.com 272 Robby Simpson 273 General Electric 275 Email: rsimpson@gmail.com