tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8030

 
 
 

Generic Event Delivery Using HTTP Push

Part 2 of 2, p. 20 to 31
Prev Section

 


prevText      Top      ToC       Page 20 
7.  Operational Considerations

7.1.  Load Management

   A push service is likely to have to maintain a very large number of
   open TCP connections.  Effective management of those connections can
   depend on being able to move connections between server instances.

   A user agent MUST support the 307 (Temporary Redirect) status code
   [RFC7231], which can be used by a push service to redistribute load
   at the time that a new subscription is requested.

   A server that wishes to redistribute load can do so using HTTP
   alternative services [RFC7838].  HTTP alternative services allows for
   redistribution of load while maintaining the same URIs for various
   resources.  A user agent can ensure a graceful transition by using
   the GOAWAY frame once it has established a replacement connection.

7.2.  Push Message Expiration

   Storage of push messages based on the TTL header field comprises a
   potentially significant amount of storage for a push service.  A push
   service is not obligated to store messages indefinitely.  A push
   service is able to indicate how long it intends to retain a message
   to an application server using the TTL header field (Section 5.2).

   A user agent that does not actively monitor for push messages will
   not receive messages that expire during that interval.

   Push messages that are stored and have not been delivered to a user
   agent are delivered when the user agent recommences monitoring.
   Stored push messages SHOULD include a Last-Modified header field
   (Section 2.2 of [RFC7232]) indicating when delivery was requested by
   an application server.

   A GET request to a push message subscription resource with only
   expired messages results in a response as though no push message was
   ever sent.

   Push services might need to limit the size and number of stored push
   messages to avoid overloading.  To limit the size of messages, the
   push service MAY return a 413 (Payload Too Large) status code
   [RFC7231] in response to requests that include an entity body that is
   too large.  Push services MUST NOT return a 413 status code in
   responses to an entity body that is 4096 bytes or less in size.

Top      Up      ToC       Page 21 
   To limit the number of stored push messages, the push service MAY
   respond with a shorter Time-To-Live than proposed by the application
   server in its request for push message delivery (Section 5.2).  Once
   a message has been accepted, the push service MAY later expire the
   message prior to its advertised Time-To-Live.  If the application
   server requested a delivery receipt, the push service MUST return a
   failure response (Section 6.2).

7.3.  Subscription Expiration

   In some cases, it may be necessary to terminate subscriptions so that
   they can be refreshed.  This applies to both push message
   subscriptions and receipt subscriptions.

   A push service MAY expire a subscription at any time.  If there are
   outstanding requests to an expired push message subscription resource
   (Section 6) from a user agent or to an expired receipt subscription
   resource (Section 6.3) from an application server, this MUST be
   signaled by returning a 404 (Not Found) status code.

   A push service MUST return a 404 (Not Found) status code if an
   application server attempts to send a push message to an expired push
   message subscription.

   A user agent can remove its push message subscription by sending a
   DELETE request to the corresponding URI.  An application server can
   remove its receipt subscription by sending a DELETE request to the
   corresponding URI.

7.3.1.  Subscription Set Expiration

   A push service MAY expire a subscription set at any time and MUST
   also expire all push message subscriptions in the set.  If a user
   agent has an outstanding request to a push subscription set
   (Section 6.1), this MUST be signaled by returning a 404 (Not Found)
   status code.

   A user agent can request that a subscription set be removed by
   sending a DELETE request to the subscription set URI.  This MUST also
   remove all push message subscriptions in the set.

   If a specific push message subscription that is a member of a
   subscription set is expired or removed, then it MUST also be removed
   from its subscription set.

Top      Up      ToC       Page 22 
7.4.  Implications for Application Reliability

   A push service that does not support reliable delivery over
   intermittent network connections or failing applications on devices,
   forces the device to acknowledge receipt directly to the application
   server, incurring additional power drain in order to establish and
   maintain (usually secure) connections to the individual application
   servers.

   Push message reliability can be important if messages contain
   information critical to the state of an application.  Repairing the
   state can be expensive, particularly for devices with limited
   communications capacity.  Knowing that a push message has been
   correctly received avoids retransmissions, polling, and state
   resynchronization.

   The availability of push message delivery receipts ensures that the
   application developer is not tempted to create alternative mechanisms
   for message delivery in case the push service fails to deliver a
   critical message.  Setting up a polling mechanism or a backup
   messaging channel in order to compensate for these shortcomings
   negates almost all of the advantages a push service provides.

   However, reliability might not be necessary for messages that are
   transient (e.g., an incoming call) or messages that are quickly
   superseded (e.g., the current number of unread emails).

7.5.  Subscription Sets and Concurrent HTTP/2 Streams

   If the push service requires that the user agent use push message
   subscription sets, then it MAY limit the number of concurrently
   active streams with the SETTINGS_MAX_CONCURRENT_STREAMS parameter
   within an HTTP/2 SETTINGS frame [RFC7540].  The user agent MAY be
   limited to one concurrent stream to manage push message subscriptions
   and one concurrent stream for each subscription set returned by the
   push service.  This could force the user agent to serialize
   subscription requests to the push service.

8.  Security Considerations

   This protocol MUST use HTTP over TLS [RFC2818] following the
   recommendations in [RFC7525].  This includes any communications
   between the user agent and the push service, plus communications
   between the application server and the push service.  All URIs
   therefore use the "https" scheme.  This provides confidentiality and
   integrity protection for subscriptions and push messages from
   external parties.

Top      Up      ToC       Page 23 
8.1.  Confidentiality from Push Service Access

   The protection afforded by TLS does not protect content from the push
   service.  Without additional safeguards, a push service can inspect
   and modify the message content.

   Applications using this protocol MUST use mechanisms that provide
   end-to-end confidentiality, integrity, and data origin
   authentication.  The application server sending the push message and
   the application on the user agent that receives it are frequently
   just different instances of the same application, so no standardized
   protocol is needed to establish a proper security context.  The
   distribution of subscription information from the user agent to its
   application server also offers a convenient medium for key agreement.

   For this requirement, the W3C Push API [API] has adopted Message
   Encryption for WebPush [ENCRYPT] to secure the content of messages
   from the push service.  Other scenarios can be addressed by similar
   policies.

   The Topic header field exposes information that allows more granular
   correlation of push messages on the same subject.  This might be used
   to aid traffic analysis of push messages by the push service.

8.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 URIs provided for push resources MUST NOT provide any basis to
   correlate communications for a given user agent.  It MUST NOT be
   possible to correlate any two push resource URIs based solely on
   their contents.  This allows a user agent to control correlation
   across different applications or over time.  Of course, this does not
   prevent correlation using other information that a user agent might
   expose.

   Similarly, the URIs provided by the push service to identify a push
   message MUST NOT provide any information that allows for correlation
   across subscriptions.  Push message URIs for the same subscription
   MAY contain information that would allow correlation with the
   associated subscription or other push messages for that subscription.

   User and device information MUST NOT be exposed through a push or
   push message URI.

Top      Up      ToC       Page 24 
   In addition, push URIs established by the same user agent or push
   message URIs for the same subscription MUST NOT include any
   information that allows them to be correlated with the user agent.

   Note:  This need not be perfect as long as the resulting anonymity
      set ([RFC6973], Section 6.1.1) is sufficiently large.  A push URI
      necessarily identifies a push service or a single server instance.
      It is also possible that traffic analysis could be used to
      correlate subscriptions.

   A user agent MUST be able to create new subscriptions with new
   identifiers at any time.

8.3.  Authorization

   This protocol does not define how a push service establishes whether
   a user agent is permitted to create a subscription, or whether push
   messages can be delivered to the user agent.  A push service MAY
   choose to authorize requests based on any HTTP-compatible
   authorization method available, of which there are multiple options
   (including experimental options) with varying levels of security.
   The authorization process and any associated credentials are expected
   to be configured in the user agent along with the URI for the push
   service.

   Authorization is managed using capability URLs for the push message
   subscription, push, and receipt subscription resources ([CAP-URI]).
   A capability URL grants access to a resource based solely on
   knowledge of the URL.

   Capability URLs are used for their "easy onward sharing" and "easy
   client API" properties.  These properties make it possible to avoid
   relying on prearranged relationships or additional protocols between
   push services and application servers.

   Capability URLs act as bearer tokens.  Knowledge of a push message
   subscription URI implies authorization to either receive push
   messages or delete the subscription.  Knowledge of a push URI implies
   authorization to send push messages.  Knowledge of a push message URI
   allows for reading and acknowledging that specific message.
   Knowledge of a receipt subscription URI implies authorization to
   receive push receipts.

   Encoding a large amount of random entropy (at least 120 bits) in the
   path component ensures that it is difficult to successfully guess a
   valid capability URL.

Top      Up      ToC       Page 25 
8.4.  Denial-of-Service Considerations

   A user agent can control where valid push messages originate by
   limiting the distribution of push URIs to authorized application
   servers.  Ensuring that push URIs are hard to guess ensures that only
   application servers that have received a push URI can use it.

   Push messages that are not successfully authenticated by the user
   agent will not be delivered, but this can present a denial-of-service
   risk.  Even a relatively small volume of push messages can cause
   battery-powered devices to exhaust power reserves.

   To address this case, the W3C Push API [API] has adopted Voluntary
   Application Server Identification [VAPID], which allows a user agent
   to restrict a subscription to a specific application server.  The
   push service can then identify and reject unwanted messages without
   contacting the user agent.

   A malicious application with a valid push URI could use the greater
   resources of a push service to mount a denial-of-service attack on a
   user agent.  Push services SHOULD limit the rate at which push
   messages are sent to individual user agents.

   A push service MAY return a 429 (Too Many Requests) status code
   [RFC6585] when an application server has exceeded its rate limit for
   push message delivery to a push resource.  The push service SHOULD
   also include a Retry-After header [RFC7231] to indicate how long the
   application server is requested to wait before it makes another
   request to the push resource.

   A push service or user agent MAY also terminate subscriptions
   (Section 7.3) that receive too many push messages.

   A push service is also able to deny service to user agents.
   Intentional failure to deliver messages is difficult to distinguish
   from faults, which might occur due to transient network errors,
   interruptions in user agent availability, or genuine service outages.

8.5.  Logging Risks

   Server request logs can reveal subscription-related URIs or
   relationships between subscription-related URIs for the same user
   agent.  Limitations on log retention and strong access control
   mechanisms can ensure that URIs are not revealed to unauthorized
   entities.

Top      Up      ToC       Page 26 
9.  IANA Considerations

   This protocol defines new HTTP header fields in Section 9.1.  New
   link relation types are identified using the URNs defined in
   Section 9.2.  Port registration is defined in Section 9.3

9.1.  Header Field Registrations

   HTTP header fields are registered within the "Message Headers"
   registry maintained at <https://www.iana.org/assignments/message-
   headers/>.

   This document defines the following HTTP header fields, and the
   following entries have been added to the "Permanent Message Header
   Field Names" registry ([RFC3864]):

   +-------------------+----------+----------+--------------+
   | Header Field Name | Protocol | Status   | Reference    |
   +-------------------+----------+----------+--------------+
   | TTL               | http     | standard | Section 5.2  |
   | Urgency           | http     | standard | Section 5.3  |
   | Topic             | http     | standard | Section 5.4  |
   +-------------------+----------+----------+--------------+

   The change controller is: "IETF (iesg@ietf.org) - Internet
   Engineering Task Force".

9.2.  Link Relation URNs

   This document registers URNs for use in identifying link relation
   types.  These have been added to a new "Web Push Identifiers"
   registry according to the procedures in Section 4 of [RFC3553]; the
   corresponding "push" sub-namespace has been entered in the "IETF URN
   Sub-namespace for Registered Protocol Parameter Identifiers"
   registry.

   The "Web Push Identifiers" registry operates under the IETF Review
   policy [RFC5226].

   Registry name:  Web Push Identifiers

   URN Prefix:  urn:ietf:params:push

   Specification:  RFC 8030 (this document)

   Repository:  http://www.iana.org/assignments/webpush-parameters/

Top      Up      ToC       Page 27 
   Index Value:  Values in this registry are URNs or URN prefixes that
      start with the prefix "urn:ietf:params:push".  Each is registered
      independently.

   Registrations in the "Web Push Identifiers" registry include the
   following information:

   URN:  A complete URN or URN prefix.

   Description:  A summary description.

   Contact:  Email for the person or group making the registration.

   Index Value:  As described in [RFC3553]

   Reference:  A reference to a specification describing the semantics
      of the URN or URN prefix.

      URN prefixes that are registered include a description of how the
      URN is constructed.  This is not applicable for specific URNs.

   These values are entered as the initial content of the "Web Push
   Identifiers" registry.

   URN:  urn:ietf:params:push

   Description:  This link relation type is used to identify a resource
      for sending push messages.

   Contact:  The WEBPUSH WG of the IETF (webpush@ietf.org)

   Reference:  RFC 8030 (this document)

   URN:  urn:ietf:params:push:set

   Description:  This link relation type is used to identify a
      collection of push message subscriptions.

   Contact:  The WEBPUSH WG of the IETF (webpush@ietf.org)

   Reference:  RFC 8030 (this document)

   URN:  urn:ietf:params:push:receipt

   Description:  This link relation type is used to identify a resource
      for receiving delivery confirmations for push messages.

   Contact:  The WEBPUSH WG of the IETF (webpush@ietf.org)

Top      Up      ToC       Page 28 
   Reference:  RFC 8030 (this document)

9.3.  Service Name and Port Number Registration

   Service names and port numbers are registered within the "Service
   Name and Transport Protocol Port Number Registry" maintained at
   <https://www.iana.org/assignments/service-names-port-numbers/>.

   In accordance with [RFC6335], IANA has assigned the System Port
   number 1001 and the service name "webpush".

   Service Name:
      webpush

   Port Number:
      1001

   Transport Protocol:
      tcp

   Description:
      HTTP Web Push

   Assignee:
      The IESG (iesg@ietf.org)

   Contact:
      The IETF Chair (chair@ietf.org)

   Reference:
      RFC 8030 (this document)

10.  References

10.1.  Normative References

   [CAP-URI]  Tennison, J., "Good Practices for Capability URLs", W3C
              First Public Working Draft capability-urls, February 2014,
              <http://www.w3.org/TR/capability-urls/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

Top      Up      ToC       Page 29 
   [RFC3553]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
              IETF URN Sub-namespace for Registered Protocol
              Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
              2003, <http://www.rfc-editor.org/info/rfc3553>.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              DOI 10.17487/RFC3864, September 2004,
              <http://www.rfc-editor.org/info/rfc3864>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <http://www.rfc-editor.org/info/rfc4648>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, DOI 10.17487/RFC5382, October 2008,
              <http://www.rfc-editor.org/info/rfc5382>.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
              DOI 10.17487/RFC5988, October 2010,
              <http://www.rfc-editor.org/info/rfc5988>.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,
              <http://www.rfc-editor.org/info/rfc6335>.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
              DOI 10.17487/RFC6454, December 2011,
              <http://www.rfc-editor.org/info/rfc6454>.

   [RFC6585]  Nottingham, M. and R. Fielding, "Additional HTTP Status
              Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
              <http://www.rfc-editor.org/info/rfc6585>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

Top      Up      ToC       Page 30 
   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <http://www.rfc-editor.org/info/rfc7231>.

   [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
              DOI 10.17487/RFC7232, June 2014,
              <http://www.rfc-editor.org/info/rfc7232>.

   [RFC7240]  Snell, J., "Prefer Header for HTTP", RFC 7240,
              DOI 10.17487/RFC7240, June 2014,
              <http://www.rfc-editor.org/info/rfc7240>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <http://www.rfc-editor.org/info/rfc7540>.

   [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <http://www.rfc-editor.org/info/rfc7838>.

10.2.  Informative References

   [API]      Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan,
              B., and E. Fullea, "Push API", W3C Editor's Draft push-
              api, November 2016, <https://w3c.github.io/push-api/>.

   [ENCRYPT]  Thomson, M., "Message Encryption for Web Push", Work in
              Progress, draft-ietf-webpush-encryption-06, October 2016.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <http://www.rfc-editor.org/info/rfc6973>.

   [VAPID]    Thomson, M. and P. Beverloo, "Voluntary Application Server
              Identification for Web Push", Work in Progress,
              draft-ietf-webpush-vapid-01, June 2016.

Top      Up      ToC       Page 31 
Acknowledgements

   Significant technical input to this document has been provided by Ben
   Bangert, Peter Beverloo, Kit Cambridge, JR Conlin, Lucas Jenss,
   Matthew Kaufman, Costin Manolache, Mark Nottingham, Idel Pivnitskiy,
   Robert Sparks, Darshak Thakore, and many others.

Authors' Addresses

   Martin Thomson
   Mozilla
   331 E Evelyn Street
   Mountain View, CA  94041
   United States of America

   Email: martin.thomson@gmail.com


   Elio Damaggio
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   United States of America

   Email: elioda@microsoft.com


   Brian Raymor (editor)
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   United States of America

   Email: brian.raymor@microsoft.com