idnits 2.17.1 draft-montenegro-httpbis-http2-server-profiles-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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 4, 2013) is 3881 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R.Peon 2 Internet Draft Google 3 Intended status: Standards Track G. Montenegro 4 Expires: March 2014 Microsoft Corporation 5 September 4, 2013 7 Profiles for Initial Server Settings 8 draft-montenegro-httpbis-http2-server-profiles-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance 13 with the provisions of BCP 78 and BCP 79. This document may 14 contain material from IETF Documents or IETF Contributions 15 published or made publicly available before November 10, 2008. 16 The person(s) controlling the copyright in some of this material 17 may not have granted the IETF Trust the right to allow 18 modifications of such material outside the IETF Standards 19 Process. Without obtaining an adequate license from the 20 person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, 22 and derivative works of it may not be created outside the IETF 23 Standards Process, except to format it for publication as an RFC 24 or to translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet 27 Engineering Task Force (IETF), its areas, and its working 28 groups. Note that other groups may also distribute working 29 documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet- 34 Drafts as reference material or to cite them other than as "work 35 in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on November, 2013. 45 Copyright 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described 57 in Section 4.e of the Trust Legal Provisions and are provided 58 without warranty as described in the Simplified BSD License. 60 Abstract 62 In HTTP/2.0, if running over TLS, the client is the first to 63 transmit HTTP/2.0 frames on the new session. With its first 64 transmission to the server, the client can already overrun some 65 of the server settings and preferences, leading to failure 66 conditions and unnecessary complexity. This document proposes a 67 solution to this problem based on a very small set of server 68 profiles for initial settings sent within the TLS handshake. 70 Table of Contents 72 1. Introduction...................................................2 73 1.1. Requirements Language.....................................3 74 2. Definition of Server Profiles for Initial Settings.............3 75 3. Usage..........................................................4 76 4. Pros and Cons of Server Profiles...............................5 77 5. Security Considerations........................................6 78 6. IANA Considerations............................................6 79 7. Acknowledgments................................................6 80 8. References.....................................................7 81 8.1. Normative References......................................7 82 8.2. Informative References....................................7 84 1. Introduction 86 In HTTP/2.0 [I-D.ietf-httpbis-http2] there is an issue with 87 unknown startup state in the TLS case (for "HTTPS"): the client 88 initiates the session by transmitting its SETTINGS and any 89 requests it wishes. However, at this time, it has not yet heard 90 the SETTINGS from the server, so the initial requests could 91 overrun some of the server's preferences. However, if the server 92 could somehow communicate its preferences to the client prior to 93 the start of the HTTP/2.0 session, then the client will not 94 overrun any of the server's preferences when it starts 95 transmitting on the new session. 97 This documents proposes a profile-based approach, based on defining 98 server profiles for initial settings sent by the server within the 99 TLS handshake: a compact server profile vs a normal server profile. 101 The profiles are communicated as part of the exchanged application- 102 layer protocol names, precisely as supported already by ALPN. 104 Of course, the compact profile is not limited to embedded/constrained 105 servers. It could be used by a regular web server if it wishes to 106 reduce its initial resource usage for new connections for whatever 107 reason. These profiles are just means to communicate initial 108 SETTINGS. These SETTINGS are no different from any other, and can be 109 subsequently modified by another SETTINGS frames, per HTTP/2.0. For 110 example, a server may use a compact profile for the beginning of a 111 session, after which it may send an updated set of SETTINGS to the 112 client, increasing the use of resources to match (or exceed) those 113 used by the normal profile. 115 A point bears repeating: this issue is only with server SETTINGS in 116 the TLS case. The profiles are only for server initial SETTINGS. The 117 client does not have this issue, as it starts the HTTP/2.0 session by 118 sending its SETTINGS (within the connection header), so when the 119 server gets a chance to initially transmit on the new session it is 120 guaranteed to have received the client SETTINGS already. As an aside, 121 in the HTTP non-TLS case (which is not the subject of this document), 122 HTTP/2.0 already fixed that by allowing the client to send its 123 settings in an HTTP/1.1 header (HTTP2-Settings). 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 128 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described 130 in RFC 2119 [RFC2119]. 132 2. Definition of Server Profiles for Initial Settings 134 There are two profiles for server initial settings: the compact 135 server profile and the normal server profile. 137 Profile 1 - constrained server profile: 139 . Negotiation strings: 140 . "H2c" for final HTTP/2.0 specification 141 . "HTTP-draft-06/2.0c" for draft version -06 142 (Appending a "c" to the negotiation string denotes the 143 "compact" profile.) 144 . SETTINGS_MAX_CONCURRENT_STREAMS: value: 1 145 . SETTINGS_INITIAL_WINDOW_SIZE: value: 2K 146 . SETTINGS_FLOW_CONTROL_OPTIONS: 0 (flow control on) 147 . SETTINGS_MAX_BUFFER_SIZE: 1K 149 Profile 2 - normal server profile 151 . Negotiation strings: 152 . "H2" for final HTTP/2.0 specification 153 . "HTTP-draft-06/2.0" for draft version -06 154 (Unchanged string implies the web server profile) 155 . SETTINGS_MAX_CONCURRENT_STREAMS: value: 100 156 . SETTINGS_INITIAL_WINDOW_SIZE: value: 64K 157 . SETTINGS_FLOW_CONTROL_OPTIONS: 0 (flow control on) 158 . SETTINGS_MAX_BUFFER_SIZE: 4K 160 These profiles are to be defined in the base HTTP/2.0 document, and 161 the negotiation strings would be registered with IANA in the ALPN 162 registry. Only the strings corresponding to the final HTTP/2.0 163 specification are to be registered in IANA. 165 Other experimental profiles could be defined for use in testing new 166 features, without need to register them in IANA. 168 3. Usage 170 The client uses ALPN to include the negotiation strings for both 171 profiles: in the TLS client hello, the client includes both of 172 these: 174 Example 1 - Profiles based on final HTTP/2.0 specification: 175 . H2c 176 . H2 178 Example 2 - Profiles based on draft versions of the HTTP/2.0 179 specifications, e.g., for draft version -06, the client includes 180 both of these: 181 . HTTP-draft-06/2.0c 182 . HTTP-draft-06/2.0 184 The server uses ALPN to respond with the negotiation string it 185 selects. For example 1, to select the compact profile the server 186 includes this in its Hello: "H2c". Alternatively, if the client had 187 proposed draft -06 (Example 2), the server would respond with "HTTP- 188 draft-04/2.0c". 190 The client interprets the returned string and sets the SETTINGS for 191 the server accordingly. The client can initiate the HTTP/2.0 session 192 (beginning with the client's SETTINGS frame) and MUST respect the 193 server SETTINGS. 195 In examples above, the client sets the server SETTINGS per the 196 compact server profile. Per usual HTTP/2.0 rules, either endpoint is 197 free to adjust their preferences by sending additional SETTINGS 198 frames. 200 Upon receipt of the client's first transmission on the HTTP/2.0 201 session, the server responds with its own SETTINGS frame, which can 202 already supersede any SETTINGS set via the server profile. This is 203 in keeping with HTTP/2.0 rules. 205 4. Pros and Cons of Server Profiles 207 Server profiles for initial settings are not the only possible 208 approach for the server to communicate its settings in advance of the 209 HTTP/2.0 session. This section compares to the other alternative that 210 has been discussed, namely, the option of augmenting the TLS 211 handshake to allow embedding the server SETTINGS (e.g., as ancillary 212 data to the application-layer protocol negotiation itself). 214 Pros: 216 . No need to modify TLS handshake any further. This is a HUGE 217 benefit, considering that ALPN has entered working group last call 218 in the TLS WG. 219 . No need to engage TLS WG (less extraneous dependencies). 220 . Simple to spec (once the profiles are agreed upon). 221 . HTTP/2.0 only needs to define the strings augmented with the 222 profiles and register those in the ALPN registry (as well as other 223 HTTPbis registries that may be applicable). 224 . This approach of profiling could be used to distinguish 225 experimental from production-grade servers. 227 . As compared to attempting to define default values for the server 228 settings, the profile approach mitigates this by not requiring ONE 229 set of defaults that must work for every type of server (which we 230 fruitlessly attempted before), but 2 sets of defaults depending on 231 the server profile. Targeting a limited set of 2 profiles should 232 make this manageable (normal web server vs compact/embedded 233 server). 235 Cons: 237 . Increases the size of the client TLS Hello as each profile would 238 imply a separate string per ALPN specs, e.g., "H2c" and "H2". Not 239 a big concern as long as we limit it to, say, 2 profiles. At any 240 rate, other TLS extensions are growing this anyway. 242 5. Security Considerations 244 None. 246 6. IANA Considerations 248 The negotiation strings must be registered with IANA's ALPN 249 registry: Application Layer Protocol Negotiation protocol byte 250 strings within the TLS section. This is not new, as HTTP/2.0 has 251 to do this anyways. This proposal just gives a certain format to 252 the strings that would ultimately be registered by HTTP/2.0. In 253 particular, the compact server profile would be denoted by the 254 string "H2c". The normal server profile would be denoted by the 255 string "H2". 257 Notice that in the interest of terseness, this proposal departs 258 from the notation currently used in HTTP/2.0. Current HTTP/2.0 259 would have the compact and normal server profiles be registered 260 as "HTTP/2.0c" and "HTTP/2.0". 262 7. Acknowledgments 264 Thanks to Mark Nottingham for useful discussions in this space. 266 This document was prepared using 2-Word-v2.0.template.doc. 268 8. References 270 8.1. Normative References 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997. 275 [I-D.ietf-httpbis-http2] 276 Belshe, M., Peon, R., Thomson, M., and A. Melnikov, 277 "Hypertext Transfer Protocol version 2.0", draft-ietf- 278 httpbis-http2 (work in progress), August 2013. 280 8.2. Informative References 282 None. 284 Author's Addresses 286 Roberto Peon 287 Google, Inc 289 Email: fenix@google.com 291 Gabriel Montenegro 292 Microsoft Corporation 294 Phone: 295 Email: gabriel.montenegro@microsoft.com