idnits 2.17.1 draft-thomson-webpush-http2-01.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 (October 8, 2014) is 3481 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) == Outdated reference: A later version (-14) exists of draft-ietf-httpbis-alt-svc-01 == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-12 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBPUSH M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track October 8, 2014 5 Expires: April 11, 2015 7 Generic Event Delivery Using HTTP Push 8 draft-thomson-webpush-http2-01 10 Abstract 12 A simple protocol for the delivery of realtime events to clients is 13 described. This scheme uses HTTP/2 push. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 11, 2015. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 51 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Delivering Push Messages . . . . . . . . . . . . . . . . . . 5 53 4. Registering . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 6. Monitoring and Receiving Push Messages . . . . . . . . . . . 6 56 7. Store and Forward Operation . . . . . . . . . . . . . . . . . 6 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 9.1. Confidentiality from Push Server Access . . . . . . . . . 7 60 9.2. Privacy Considerations . . . . . . . . . . . . . . . . . 8 61 9.3. Denial of Service Vectors . . . . . . . . . . . . . . . . 8 62 9.4. Logging Exposure . . . . . . . . . . . . . . . . . . . . 9 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 10.2. Informative References . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 Mobile computing devices are increasingly relied upon for a great 71 many applications. Mobile devices typically have limited power 72 reserves, so finding more efficient ways to serve application 73 requirements is an important part of any mobile platform. 75 One significant contributor to power usage mobile devices is the 76 radio. Radio communications consumes a significant portion of the 77 energy budget on a wirelessly connected mobile device. 79 Many applications require continuous access to network communications 80 so that real-time events - such as incoming calls or messages - can 81 be conveyed (or "pushed") to the user in a timely fashion. 82 Uncoordinated use of persistent connections or sessions from multiple 83 applications can contribute to unnecessary use of the device radio, 84 since each independent session independently incurs overheads. In 85 particular, keep alive traffic used to ensure that middleboxes do not 86 prematurely time out sessions, can result in significant waste. 87 Maintenance traffic tends to dominate over the long term, since 88 events are relatively rare. 90 Consolidating all real-time events into a single session ensures more 91 efficient use of network and radio resources. A single service 92 consolidates all events, distributing those events to applications as 93 they arrive. This requires just one session, avoiding duplicated 94 overhead costs. 96 The Web Push API [API] describes an API that enables the use of a 97 consolidated push service from web applications. This expands on 98 that work by describing a protocol that can be used to: 100 o request the delivery of an event to a device, 102 o register a new device, 104 o create new event delivery channels, and 106 o monitor for new events. 108 This is intentionally split into these two categories because 109 requesting the delivery of events is required for immediate use by 110 the Web Push API. The registration, management and monitoring 111 functions are currently fulfilled by proprietary protocols; these are 112 adequate, but do not offer any of the advantages that standardization 113 affords. 115 The monitoring function described in this document is intended to be 116 replaceable, enabling the use of monitoring schemes that are better 117 optimized for the network environment and the device. For instance, 118 using notification systems like the GSM Short Message Service (SMS) 119 can take advantage of the native paging capabilities of a cellular 120 network, avoiding the ongoing maintainence cost of a persistent TCP 121 connection. 123 This document intentionally does not describe how a push server is 124 discovered. Discovery of push servers is left for future efforts, if 125 it turns out to be necessary at all. Devices are expected to be 126 configured with a push server URL. 128 Similarly, discovery of support for and negotiation of use of 129 alternative monitoring schemes is left to documents that extend this 130 basic protocol. 132 1.1. Conventions and Terminology 134 In cases where normative language needs to be emphasized, this 135 document falls back on established shorthands for expressing 136 interoperability requirements on implementations: the capitalized 137 words "MUST", "MUST NOT", "SHOULD" and "MAY". The meaning of these 138 is described in [RFC2119]. 140 This document will use the terminology from [API], though 141 "application" will be used in preference to "webapp", since the 142 described protocols are not restricted to web use. This document 143 introduces the term "device", which refers to the consumer of push 144 messages. 146 2. Overview 148 A general model for push services includes three basic actors: a 149 device, a push server, and an application. 151 +-----------+ +-------------+ +-------------+ 152 | Device | | Push Server | | Application | 153 +-----------+ +-------------+ +-------------+ 154 | | | 155 | Register | | 156 |--------------------->| | 157 | Monitor | | 158 |<====================>| | 159 | Get Channel | | 160 |--------------------->| | 161 | Provide Channel | 162 |-------------------------------------------->| 163 | | Push Message | 164 | Push Message |<---------------------| 165 |<---------------------| | 166 | | | 168 At the very beginning of the process, the device registers with the 169 push server. This establishes a shared session between the device 170 and push server that will be used to aggregate push messages from all 171 applications that the device interacts with. 173 The registration response includes details on how the device is 174 expected to monitor for incoming push messages. This document 175 describes one such mechanism, though more efficient means of 176 monitoring could be optionally defined (and this is expressly 177 permitted). 179 A registration after creation has no channels associated with it. 180 New channels can be requested by the device and then distributed to 181 applications. It is expected that devices will distribute a 182 different channel to each application, with the potential for 183 multiple channels being provided to the same application. 185 Applications use channels to deliver push messages to devices, via 186 the push server. 188 Both registrations and channels have a limited lifetime. These will 189 need to be refreshed or replaced over time. 191 3. Delivering Push Messages 193 A push channel is identified with an HTTP URI [RFC7230]. An 194 application can request the delivery of a push message by sending an 195 HTTP PUT request to this URI, including the push message in the body 196 of the request. 198 A push server can acknowledge the end-to-end delivery of a push 199 message by responding with a 200 (OK) status code. A push server 200 that stores the message for later delivery (see Section 7) could 201 respond with a 202 (Accepted) status code to indicate that the 202 message was stored, but not delivered. 204 4. Registering 206 A device that wishes to establish a new or replacement registration 207 sends an HTTP POST request to its configured push server URL. The 208 request contains no entity body. 210 The push server creates a new registration in response to this 211 request, creating two new resources and allocating an HTTP URI for 212 each. These URIs are included in link relations [RFC5988] that are 213 included in Link header fields in the response. 215 monitor: A link relation of type "...:push:monitor" includes the URL 216 of a resource that the device can monitor for events. Monitoring 217 is described in Section 6. 219 channel: A link relation of type "...:push:channel" includes a URL 220 of a resource where the device can create new channels. Creating 221 channels is described in Section 5. 223 The push server includes the "monitor" link relation in a Location 224 header field. 226 The push server MUST include expiration information in the response 227 to this request in either the Expires header field, or by setting a 228 "max-age" parameter on a Cache-Control header field. The Cache- 229 Control header field MUST include the "private" directive [RFC7235]. 231 The push server SHOULD also provide the "channel" link and expiration 232 information in response to requests to the "monitor" resource. 234 A device MUST support the 307 (Temporary Redirect) status code 235 [RFC7231], which can be used by a push server to redistribute load at 236 the time a registration is created. 238 5. Channels 240 A client sends a POST request to the "channel" resource to create a 241 new channel. 243 A response with a 201 status code includes the channel URI in the 244 Location header field. 246 A channel can expire. Servers indicate this using the Expires header 247 field, or by setting a "max-age" parameter on a Cache-Control header 248 field. 250 A client can explicitly delete a channel by sending a DELETE request 251 to channel URI. 253 6. Monitoring and Receiving Push Messages 255 A device monitors for new events by making a GET request to the 256 monitor resource. The server does not respond to these request, it 257 instead uses server push [I-D.ietf-httpbis-http2] to send the 258 contents of push messages as applications send them. 260 Each push message consists of a synthesized GET request to the 261 channel URI that was the target of the push. The response body is 262 the entity body from the PUT request. 264 A device can request the monitor resource immediately by including a 265 Prefer header field [RFC7240] with a "wait" parameter set to "0". 266 This allows clients to rapidly check for any missed messages. 267 Clients can check the status of individual channels by sending GET 268 requests to the channel URI. 270 A server that wishes to redistribute load can do so using the 271 alternative services mechanisms that are part of HTTP/2 272 [I-D.ietf-httpbis-alt-svc]. The ALTSVC frame type allows for 273 redistribution of load whilst retaining the same monitor resource. 274 Once a device has established a replacement connection, it can notify 275 the server of imminent shutdown using a GOAWAY frame, which allows 276 the server to respond to the long-standing GET request and gracefully 277 shut down the connection. This allows for seamless migration between 278 servers. 280 7. Store and Forward Operation 282 Push servers are not obligated to store messages for any time. If a 283 client is not actively monitoring for push messages, messages can be 284 lost. 286 Push servers can store messages for some time to allow for limited 287 recovery from transient faults. If a message is stored, but not 288 delivered, the push server can indicate the probable duration of 289 storage by including expiration information in the response to the 290 push request. 292 Messages that were stored and not delivered to a client MAY be 293 delivered when a client commences monitoring. These messages should 294 include a Last-Modified header field. If a server stores push 295 messages, a GET request to a channel URI returns the last message 296 sent by an application to that channel. 298 Push servers that store push messages might need to limit the size of 299 push messages to avoid being subject to overloading. Push servers 300 that don't store can stream the payload of push messages to devices. 301 This can use HTTP/2 flow control to limit the state commitment this 302 requires. However, push servers MAY place an upper limit on the size 303 of push messages that they permit. 305 8. IANA Considerations 307 TODO: register link relation types, as necessary. 309 9. Security Considerations 311 This protocol MUST use HTTP over TLS [RFC2818]; this includes any 312 communications between device and push server, plus communications 313 between the application and the push server. This provides 314 confidentiality and integrity protection for registrations and push 315 message. 317 9.1. Confidentiality from Push Server Access 319 The protection afforded by TLS does not protect content from the push 320 server. A push server is able to see and modify the content of the 321 messages. 323 Applications are able to provide additional confidentiality, 324 integrity or authentication mechanisms within the push message 325 itself. The originating application server and the device are 326 frequently just different instances of the same application, this 327 does not require standardization. The process of registering a 328 channel endpoints provides a convenient medium for key agreement. 330 In particular, the W3C Web Push API requires that each push channel 331 created by the browser be bound to a browser generated encryption 332 key. Pushed messages are authenticated and decrypted by the browser 333 before delivery. This ensures that the push server is unable to 334 examine the contents of push messages. 336 The public key for a channel ensures that applications using a 337 channel can identify messages from unknown sources and discard them. 338 This depends on the public key only being disclosed to entities that 339 are authorized to send messages on the channel. The push server does 340 not require access to this public key. 342 9.2. Privacy Considerations 344 Push message confidentiality does not ensure that the identity of who 345 is communicating and when they are communicating is protected. 346 However, the amount of information that is exposed can be limited. 348 The identifiers used by this protocol provide some ability to 349 correlate communications for a given device, either across 350 applications or over time. Most important is that communications for 351 a given device not be able to be correlated between different 352 application usages, or between different times. 354 Channel URIs established by the same device MUST NOT include any 355 information that allows them to be correlated with other channels or 356 the device registration. The push server is the only entity that 357 needs to be able to correlate channel URIs with device registrations. 358 Note that this can't prevent the use of traffic analysis in 359 performing correlation. 361 A device MUST be able to create new registrations at any time. 362 Identifiers for new registrations MUST NOT include any information 363 that allows them to be correlated with other registrations from the 364 same device or user. 366 9.3. Denial of Service Vectors 368 This protocol does not specify a single authorization framework for 369 managing access to push servers, either by devices or applications. 370 Thus, there is a very real possibility that this could be exploited 371 to mount denial of service attacks on the push server. Push servers 372 MAY choose to authorize requests based on any HTTP-compatible means 373 available, of which there are numerous options. 375 Discarding unwanted messages at the device based on message 376 authentication doesn't protect against a denial of service attack on 377 the device. Even a relatively small number of message can cause 378 devices to exhaust batteries. Limiting the number of entities with 379 access to push channels limits the number of entities that can 380 generate value push requests of the push server. An application can 381 do this by controlling the distribution of channel URIs to authorized 382 entities. 384 Only the push server can make this denial of service protection 385 possible. A push server MUST generate channel URI that are extremely 386 difficult to guess. Encoding a large amount of random entropy (at 387 least 128 bits) in the URI path is one technique for ensuring that 388 channel URIs are able to act as bearer tokens. 390 A malicious application can use the greater resources of a push 391 server to mount a denial of service attack on devices. Push servers 392 SHOULD limit the rate at which push messages are sent to devices. 394 Conversely, a push server is also able to deny service to devices. 395 Intentional failure to deliver messages is difficult to distinguish 396 from faults, which might occur due to transient network errors, 397 interruptions in device availability, or genuine service outages. 398 Applications that rely on reliable message delivery need to provide 399 means of recovering from occasional failures that do not rely on push 400 notifications. 402 9.4. Logging Exposure 404 Server request logs can reveal registration and channel URIs. 405 Acquiring a registration URI permits the creation of new channels and 406 the receipt of messages. Acquiring either URI permits the generation 407 of push messages. Logging could also reveal relationships between 408 different channel URIs for the same registration, or between 409 different registrations for the same device. 411 End-to-end confidentiality mechanisms, such as those in [API], 412 prevent an entity with a registration URI from learning the contents 413 of push messages. In both cases, push messages that are not 414 successfully authenticated will not be delivered by the API, but this 415 can present a denial of service risk. Limitations on log retention 416 and strong access control mechanisms can ensure that these URIs are 417 not learned. 419 10. References 421 10.1. Normative References 423 [I-D.ietf-httpbis-alt-svc] 424 Nottingham, M., McManus, P., and J. Reschke, "HTTP 425 Alternative Services", draft-ietf-httpbis-alt-svc-01 (work 426 in progress), April 2014. 428 [I-D.ietf-httpbis-http2] 429 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 430 Protocol version 2", draft-ietf-httpbis-http2-12 (work in 431 progress), April 2014. 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, March 1997. 436 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 438 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 440 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 441 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 442 2014. 444 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 445 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 447 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 448 (HTTP/1.1): Authentication", RFC 7235, June 2014. 450 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014. 452 10.2. Informative References 454 [API] Sullivan, B. and E. Fullea, "Web Push API", Editor's Draft 455 push-api, May 2014, . 458 Author's Address 460 Martin Thomson 461 Mozilla 462 331 E Evelyn Street 463 Mountain View, CA 94041 464 US 466 Email: martin.thomson@gmail.com