| WEBPUSH | M. Thomson |
| Internet-Draft | Mozilla |
| Intended status: Standards Track | October 8, 2014 |
| Expires: April 11, 2015 |
Generic Event Delivery Using HTTP Push
draft-thomson-webpush-http2-01
A simple protocol for the delivery of realtime events to clients is described. This scheme uses HTTP/2 push.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 11, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Mobile computing devices are increasingly relied upon for a great many applications. Mobile devices typically have limited power reserves, so finding more efficient ways to serve application requirements is an important part of any mobile platform.
One significant contributor to power usage mobile devices is the radio. Radio communications consumes a significant portion of the energy budget on a wirelessly connected mobile device.
Many applications require continuous access to network communications so that real-time events - such as incoming calls or messages - can be conveyed (or "pushed") to the user in a timely fashion. Uncoordinated use of persistent connections or sessions from multiple applications can contribute to unnecessary use of the device radio, since each independent session independently incurs overheads. In particular, keep alive traffic used to ensure that middleboxes do not prematurely time out sessions, can result in significant waste. Maintenance traffic tends to dominate over the long term, since events are relatively rare.
Consolidating all real-time events into a single session ensures more efficient use of network and radio resources. A single service consolidates all events, distributing those events to applications as they arrive. This requires just one session, avoiding duplicated overhead costs.
The Web Push API [API] describes an API that enables the use of a consolidated push service from web applications. This expands on that work by describing a protocol that can be used to:
This is intentionally split into these two categories because requesting the delivery of events is required for immediate use by the Web Push API. The registration, management and monitoring functions are currently fulfilled by proprietary protocols; these are adequate, but do not offer any of the advantages that standardization affords.
The monitoring function described in this document is intended to be replaceable, enabling the use of monitoring schemes that are better optimized for the network environment and the device. For instance, using notification systems like the GSM Short Message Service (SMS) can take advantage of the native paging capabilities of a cellular network, avoiding the ongoing maintainence cost of a persistent TCP connection.
This document intentionally does not describe how a push server is discovered. Discovery of push servers is left for future efforts, if it turns out to be necessary at all. Devices are expected to be configured with a push server URL.
Similarly, discovery of support for and negotiation of use of alternative monitoring schemes is left to documents that extend this basic protocol.
In cases where normative language needs to be emphasized, this document falls back on established shorthands for expressing interoperability requirements on implementations: the capitalized words "MUST", "MUST NOT", "SHOULD" and "MAY". The meaning of these is described in [RFC2119].
This document will use the terminology from [API], though "application" will be used in preference to "webapp", since the described protocols are not restricted to web use. This document introduces the term "device", which refers to the consumer of push messages.
A general model for push services includes three basic actors: a device, a push server, and an application.
+-----------+ +-------------+ +-------------+
| Device | | Push Server | | Application |
+-----------+ +-------------+ +-------------+
| | |
| Register | |
|--------------------->| |
| Monitor | |
|<====================>| |
| Get Channel | |
|--------------------->| |
| Provide Channel |
|-------------------------------------------->|
| | Push Message |
| Push Message |<---------------------|
|<---------------------| |
| | |
At the very beginning of the process, the device registers with the push server. This establishes a shared session between the device and push server that will be used to aggregate push messages from all applications that the device interacts with.
The registration response includes details on how the device is expected to monitor for incoming push messages. This document describes one such mechanism, though more efficient means of monitoring could be optionally defined (and this is expressly permitted).
A registration after creation has no channels associated with it. New channels can be requested by the device and then distributed to applications. It is expected that devices will distribute a different channel to each application, with the potential for multiple channels being provided to the same application.
Applications use channels to deliver push messages to devices, via the push server.
Both registrations and channels have a limited lifetime. These will need to be refreshed or replaced over time.
A push channel is identified with an HTTP URI [RFC7230]. An application can request the delivery of a push message by sending an HTTP PUT request to this URI, including the push message in the body of the request.
A push server can acknowledge the end-to-end delivery of a push message by responding with a 200 (OK) status code. A push server that stores the message for later delivery (see Section 7) could respond with a 202 (Accepted) status code to indicate that the message was stored, but not delivered.
A device that wishes to establish a new or replacement registration sends an HTTP POST request to its configured push server URL. The request contains no entity body.
The push server creates a new registration in response to this request, creating two new resources and allocating an HTTP URI for each. These URIs are included in link relations [RFC5988] that are included in Link header fields in the response.
The push server includes the "monitor" link relation in a Location header field.
The push server MUST include expiration information in the response to this request in either the Expires header field, or by setting a "max-age" parameter on a Cache-Control header field. The Cache-Control header field MUST include the "private" directive [RFC7235].
The push server SHOULD also provide the "channel" link and expiration information in response to requests to the "monitor" resource.
A device MUST support the 307 (Temporary Redirect) status code [RFC7231], which can be used by a push server to redistribute load at the time a registration is created.
A client sends a POST request to the "channel" resource to create a new channel.
A response with a 201 status code includes the channel URI in the Location header field.
A channel can expire. Servers indicate this using the Expires header field, or by setting a "max-age" parameter on a Cache-Control header field.
A client can explicitly delete a channel by sending a DELETE request to channel URI.
A device monitors for new events by making a GET request to the monitor resource. The server does not respond to these request, it instead uses server push [I-D.ietf-httpbis-http2] to send the contents of push messages as applications send them.
Each push message consists of a synthesized GET request to the channel URI that was the target of the push. The response body is the entity body from the PUT request.
A device can request the monitor resource immediately by including a Prefer header field [RFC7240] with a "wait" parameter set to "0". This allows clients to rapidly check for any missed messages. Clients can check the status of individual channels by sending GET requests to the channel URI.
A server that wishes to redistribute load can do so using the alternative services mechanisms that are part of HTTP/2 [I-D.ietf-httpbis-alt-svc]. The ALTSVC frame type allows for redistribution of load whilst retaining the same monitor resource. Once a device has established a replacement connection, it can notify the server of imminent shutdown using a GOAWAY frame, which allows the server to respond to the long-standing GET request and gracefully shut down the connection. This allows for seamless migration between servers.
Push servers are not obligated to store messages for any time. If a client is not actively monitoring for push messages, messages can be lost.
Push servers can store messages for some time to allow for limited recovery from transient faults. If a message is stored, but not delivered, the push server can indicate the probable duration of storage by including expiration information in the response to the push request.
Messages that were stored and not delivered to a client MAY be delivered when a client commences monitoring. These messages should include a Last-Modified header field. If a server stores push messages, a GET request to a channel URI returns the last message sent by an application to that channel.
Push servers that store push messages might need to limit the size of push messages to avoid being subject to overloading. Push servers that don't store can stream the payload of push messages to devices. This can use HTTP/2 flow control to limit the state commitment this requires. However, push servers MAY place an upper limit on the size of push messages that they permit.
TODO: register link relation types, as necessary.
This protocol MUST use HTTP over TLS [RFC2818]; this includes any communications between device and push server, plus communications between the application and the push server. This provides confidentiality and integrity protection for registrations and push message.
The protection afforded by TLS does not protect content from the push server. A push server is able to see and modify the content of the messages.
Applications are able to provide additional confidentiality, integrity or authentication mechanisms within the push message itself. The originating application server and the device are frequently just different instances of the same application, this does not require standardization. The process of registering a channel endpoints provides a convenient medium for key agreement.
In particular, the W3C Web Push API requires that each push channel created by the browser be bound to a browser generated encryption key. Pushed messages are authenticated and decrypted by the browser before delivery. This ensures that the push server is unable to examine the contents of push messages.
The public key for a channel ensures that applications using a channel can identify messages from unknown sources and discard them. This depends on the public key only being disclosed to entities that are authorized to send messages on the channel. The push server does not require access to this public key.
Push message confidentiality does not ensure that the identity of who is communicating and when they are communicating is protected. However, the amount of information that is exposed can be limited.
The identifiers used by this protocol provide some ability to correlate communications for a given device, either across applications or over time. Most important is that communications for a given device not be able to be correlated between different application usages, or between different times.
Channel URIs established by the same device MUST NOT include any information that allows them to be correlated with other channels or the device registration. The push server is the only entity that needs to be able to correlate channel URIs with device registrations. Note that this can't prevent the use of traffic analysis in performing correlation.
A device MUST be able to create new registrations at any time. Identifiers for new registrations MUST NOT include any information that allows them to be correlated with other registrations from the same device or user.
This protocol does not specify a single authorization framework for managing access to push servers, either by devices or applications. Thus, there is a very real possibility that this could be exploited to mount denial of service attacks on the push server. Push servers MAY choose to authorize requests based on any HTTP-compatible means available, of which there are numerous options.
Discarding unwanted messages at the device based on message authentication doesn't protect against a denial of service attack on the device. Even a relatively small number of message can cause devices to exhaust batteries. Limiting the number of entities with access to push channels limits the number of entities that can generate value push requests of the push server. An application can do this by controlling the distribution of channel URIs to authorized entities.
Only the push server can make this denial of service protection possible. A push server MUST generate channel URI that are extremely difficult to guess. Encoding a large amount of random entropy (at least 128 bits) in the URI path is one technique for ensuring that channel URIs are able to act as bearer tokens.
A malicious application can use the greater resources of a push server to mount a denial of service attack on devices. Push servers SHOULD limit the rate at which push messages are sent to devices. [CREF2]...this suggests a mechanism whereby the server can inform devices when it terminates channels or entire registrations.
Conversely, a push server is also able to deny service to devices. Intentional failure to deliver messages is difficult to distinguish from faults, which might occur due to transient network errors, interruptions in device availability, or genuine service outages. Applications that rely on reliable message delivery need to provide means of recovering from occasional failures that do not rely on push notifications.
Server request logs can reveal registration and channel URIs. Acquiring a registration URI permits the creation of new channels and the receipt of messages. Acquiring either URI permits the generation of push messages. Logging could also reveal relationships between different channel URIs for the same registration, or between different registrations for the same device.
End-to-end confidentiality mechanisms, such as those in [API], prevent an entity with a registration URI from learning the contents of push messages. In both cases, push messages that are not successfully authenticated will not be delivered by the API, but this can present a denial of service risk. Limitations on log retention and strong access control mechanisms can ensure that these URIs are not learned.
| [API] | Sullivan, B. and E. Fullea, "Web Push API", Editor's Draft push-api, May 2014. |