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

Abstract

   A simple protocol for the delivery of realtime events to clients is
   described.  This scheme uses HTTP/2 push.

Status of This Memo

   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 Notice

   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.






Thomson                  Expires April 11, 2015                 [Page 1]


Internet-Draft                HTTP Web Push                 October 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Delivering Push Messages  . . . . . . . . . . . . . . . . . .   5
   4.  Registering . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Channels  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Monitoring and Receiving Push Messages  . . . . . . . . . . .   6
   7.  Store and Forward Operation . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     9.1.  Confidentiality from Push Server Access . . . . . . . . .   7
     9.2.  Privacy Considerations  . . . . . . . . . . . . . . . . .   8
     9.3.  Denial of Service Vectors . . . . . . . . . . . . . . . .   8
     9.4.  Logging Exposure  . . . . . . . . . . . . . . . . . . . .   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   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.



Thomson                  Expires April 11, 2015                 [Page 2]


Internet-Draft                HTTP Web Push                 October 2014


   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:

   o  request the delivery of an event to a device,

   o  register a new device,

   o  create new event delivery channels, and

   o  monitor for new events.

   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.

1.1.  Conventions and Terminology

   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




Thomson                  Expires April 11, 2015                 [Page 3]


Internet-Draft                HTTP Web Push                 October 2014


   introduces the term "device", which refers to the consumer of push
   messages.

2.  Overview

   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.




Thomson                  Expires April 11, 2015                 [Page 4]


Internet-Draft                HTTP Web Push                 October 2014


3.  Delivering Push Messages

   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.

4.  Registering

   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.

   monitor:  A link relation of type "...:push:monitor" includes the URL
      of a resource that the device can monitor for events.  Monitoring
      is described in Section 6.

   channel:  A link relation of type "...:push:channel" includes a URL
      of a resource where the device can create new channels.  Creating
      channels is described in Section 5.

   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.





Thomson                  Expires April 11, 2015                 [Page 5]


Internet-Draft                HTTP Web Push                 October 2014


5.  Channels

   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.

6.  Monitoring and Receiving Push Messages

   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.

7.  Store and Forward Operation

   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.




Thomson                  Expires April 11, 2015                 [Page 6]


Internet-Draft                HTTP Web Push                 October 2014


   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.

8.  IANA Considerations

   TODO: register link relation types, as necessary.

9.  Security Considerations

   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.

9.1.  Confidentiality from Push Server Access

   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




Thomson                  Expires April 11, 2015                 [Page 7]


Internet-Draft                HTTP Web Push                 October 2014


   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.

9.2.  Privacy Considerations

   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.

9.3.  Denial of Service Vectors

   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



Thomson                  Expires April 11, 2015                 [Page 8]


Internet-Draft                HTTP Web Push                 October 2014


   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.

   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.

9.4.  Logging Exposure

   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.

10.  References

10.1.  Normative References

   [I-D.ietf-httpbis-alt-svc]
              Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", draft-ietf-httpbis-alt-svc-01 (work
              in progress), April 2014.





Thomson                  Expires April 11, 2015                 [Page 9]


Internet-Draft                HTTP Web Push                 October 2014


   [I-D.ietf-httpbis-http2]
              Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
              Protocol version 2", draft-ietf-httpbis-http2-12 (work in
              progress), April 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 2010.

   [RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
              2014.

   [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

   [RFC7235]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Authentication", RFC 7235, June 2014.

   [RFC7240]  Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014.

10.2.  Informative References

   [API]      Sullivan, B. and E. Fullea, "Web Push API", Editor's Draft
              push-api, May 2014, <https://w3c.github.io/push-api/
              index.html>.

Author's Address

   Martin Thomson
   Mozilla
   331 E Evelyn Street
   Mountain View, CA  94041
   US

   Email: martin.thomson@gmail.com












Thomson                  Expires April 11, 2015                [Page 10]