Network Working Group G. Eriksson
Internet-Draft C. Holmberg
Intended status: Informational Z. Sarker
Expires: May 4, 2017 Ericsson
J. Reschke
greenbytes
October 31, 2016
Resource Maps
draft-eriksson-http-resource-map-00
Abstract
When the 'out-of-band' content coding ('OOB') is used for delivering
a number of resources from a primary server via a secondary server,
the additional round trips for OOB responses and load on the primary
server can be a significant nuisance.
In such situations, it is useful for the primary server to be able to
provide the client with OOB response information for several
resources in one go anticipating future client requests.
This document describes a format for providing the client with the
information, called a resource map, and how the resource map could be
delivered to a client.
Editorial Note (To be removed by RFC Editor before publication)
Distribution of this document is unlimited. Although this is not a
work item of the HTTPbis Working Group, comments should be sent to
the Hypertext Transfer Protocol (HTTP) mailing list at
ietf-http-wg@w3.org [1], which may be joined by sending a message
with subject "subscribe" to ietf-http-wg-request@w3.org [2].
Discussions of the HTTPbis Working Group are archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
XML versions, latest edits, and issue tracking for this document are
available from
<https://github.com/EricssonResearch/Blind-Cache-Drafts>.
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
Eriksson, et al. Expires May 4, 2017 [Page 1]
Internet-Draft Resource Maps October 2016
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 May 4, 2017.
Copyright Notice
Copyright (c) 2016 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.
Eriksson, et al. Expires May 4, 2017 [Page 2]
Internet-Draft Resource Maps October 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
2. Basic procedure for providing a Resource Map . . . . . . . . . 4
3. Updating the Resource Map . . . . . . . . . . . . . . . . . . 6
3.1. Primary server need to update Resource Map . . . . . . . . 6
3.2. Piggyback . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Using Web Push . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Continuous Updates . . . . . . . . . . . . . . . . . . . . 7
3.5. Resource Map Timer . . . . . . . . . . . . . . . . . . . . 7
3.6. Resource Map compression . . . . . . . . . . . . . . . . . 7
3.6.1. gzip . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6.2. Formulas . . . . . . . . . . . . . . . . . . . . . . . 7
4. The Resource Map format . . . . . . . . . . . . . . . . . . . 8
4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Updates for Resource Map . . . . . . . . . . . . . . . . . 8
4.3. Secondary Servers and Mapping of Resources . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Multiple Secondary Servers . . . . . . . . . . . . . 11
Appendix B. Change Log (To be removed before publication as
RFC . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Eriksson, et al. Expires May 4, 2017 [Page 3]
Internet-Draft Resource Maps October 2016
1. Introduction
The mechanisms outlined in "An Architecture for Secure Content
Delegation using HTTP" [SCD] and "Caching Secure HTTP Content using
Blind Caches" [BC] use the 'out-of-band' content coding ('OOB')
mechanism [OOBENC] to delegate the delivery of requested resource
from a primary server to one or several secondary servers.
A primary server might decide to delegate the delivery of response
payload for a set of resources, for instance individual video
segments, or a set of images or parts of a large file.
In one approach the client sends individual requests for each of the
resources to the primary server which provides the OOB content coding
response information for the requested resources as meta data in each
and every request to the primary server. This approach adds a
minimum of one extra RTT (round trip time) for each request before
the client can send the request to the desired secondary server.
In another approach the primary server anticipates a client's
requests, for instance leveraging object dependency graph
information, to provide the client with OOB content coding
information for the subsequent requests in advance of requests.
This document describes a format for providing the client with the
information for multipe OOB responses, called a resource map, and how
the information is delivered to a client.
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Basic procedure for providing a Resource Map
A primary server creates a resource map containing information about
how a set of resources on the origin it serves maps to a set of
resource locations on one or multiple secondary servers.
[OOBENC] describes the basic procedure for providing the client with
the OOB response meta data for an individual request, as examplified
below:
Client request of a resource:
Eriksson, et al. Expires May 4, 2017 [Page 4]
Internet-Draft Resource Maps October 2016
GET /test HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip, out-of-band
Response from primary server:
HTTP/1.1 200 OK
Date: Thu, 14 May 2015 18:52:00 GMT
Content-Type: text/plain
Cache-Control: max-age=10, public
Content-Encoding: out-of-band
Content-Length: 165
Vary: Accept-Encoding
{
"sr": [
{ "r" :
"http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"},
{ "r" :
"/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"}
]
}
A primary server can provide a Resource Map location in any response
to a request for any resource using a Link header field [RFC5988] --
this can be an OOB response like the one above, but doesn't need to.
Link: </map>; rel="http://purl.org/NET/linkrel/resource-map"
Note that in this example, "/map" is a relative reference identifying
the resource map (relative to the request URI), and
"http://purl.org/NET/linkrel/resource-map" is the identifier for the
link relation "resource map".
A primary server can speculatively anticipate a client requesting a
Resource Map and MAY use HTTP/2 [RFC7540] to push the response with
the Resource Map to the client to decrease the extra delay a request
for resource map otherwise would incur.
The basic operation for providing the client with a Resource Map is
as follows:
1. Client requests resource from primary. Request includes Accept-
Encoding header field including "out-of-band".
2. Primary server response includes Link header field identifying
the resource map.
Eriksson, et al. Expires May 4, 2017 [Page 5]
Internet-Draft Resource Maps October 2016
3. Client retrieves the resource map.
4. Resource Map becomes stale and will be retrieved again.
3. Updating the Resource Map
3.1. Primary server need to update Resource Map
Depending on the nature of the application and the resources, the
primary server's need to provide the client with updates of the
resource map information vary. In some cases there is no or little
need for updates, in others there may be reasons for more frequent
updates.
For instance, delegation information for static resources such as
banners, images and script libraries for analytics might not change.
In such a situation, the primary server does not need to stay in
touch with the client to provide it with updates.
In another use case, the primary server provides the client with
updates, for instance changing the secondary servers to be used by a
mobile client.
Basically there are four approaches for a primary server to provide a
client with updates to a resource map:
o Piggyback signal about update on response to request from client
o Client subscribes to Web Push updates
o Client receives continuous updates
o Resource Map validity time-out
3.2. Piggyback
A primary server MAY add an Link header field to any response to a
client. A client receiving a response with a Link header MUST
retrieve the Resource Map web resource and process it.
3.3. Using Web Push
A primary server MAY add an indication in the Resource Map to the
client to use a notification service to receive updates to a Resource
Map. When present a client SHOULD register for notifications.
A client receiving a Resource Map update notification MUST retrieve
the Resource Map using the location information in the notification.
Eriksson, et al. Expires May 4, 2017 [Page 6]
Internet-Draft Resource Maps October 2016
3.4. Continuous Updates
In some situations, it is desirable to provide the client with a
stream of Resource Map updates. Depending on the client type, either
a secure bi-directional transport protocol is used, such as
WebSocket, or the client is instructed to poll for changes.
A primary server MAY add an indication to the client to either poll
or use a stream oriented protocol for receiving intermittent,
frequent updates.
3.5. Resource Map Timer
The freshness of a Resource Map can be given by the 'ma' timer. When
expired, the OOB delegation is not valid and the client MUST request
an update from the primary server (this duplicates HTTP cache
information, but might become important when the resource map is
transmitted over a protocol other than HTTP).
3.6. Resource Map compression
3.6.1. gzip
A resource map might be large. For this reason a client can use
compression content codings such as 'gzip' to decrease the size.
3.6.2. Formulas
When using the resource map, the primary server could use a template
or formula to optimize the size of the resource map information. For
example, using URI templates [RFC6570], and an agreed upon HMAC of
the path postfix, it would be possible to specify a mapping for many
URIs at once.
originURI =
"https://{origin}/images/{postfix}
mappedURI =
"https://cch.example.com/{origin}/images/{hmac-of-postfix}
...would indicate a mapping for any https URI on "origin" below a
root path of "/images/", where the mapped URI would be constructed by
concatenating "https://cch.example.com/", the origin's host name,
"/images/", and a base64- or hex-encoded opaque part, computed based
on the remainder of the origin URI's path.
Eriksson, et al. Expires May 4, 2017 [Page 7]
Internet-Draft Resource Maps October 2016
4. The Resource Map format
4.1. Definitions
A resource map will use and extend attributes outlined in [OOBENC] as
well as additional extension attributes to be defined later.
The format of the resource map uses JavaScript Object Notation (JSON,
[RFC7159]) describing a set of objects:
o Objects for describing handling of updates of a resource map.
o Objects for describing secondary servers and which resources that
are mapped.
o Objects for describing the resources on the secondary servers.
{
"resource-map-updates" : {
//Information about resource map updates.
},
"secondary-servers" : {
//Information about secondary servers.
},
"resources" : [
//Information about resources on secondary servers.
]
}
4.2. Updates for Resource Map
[[anchor15: Details to be done. Example below illustrates how this
could be used.]]
Eriksson, et al. Expires May 4, 2017 [Page 8]
Internet-Draft Resource Maps October 2016
{
"resource-map-updates" : {
"max-age" : [ ],
"web push" : {
"notification service" : [ ] // URL
... // Other Web Push details
},
"online" : {
"poll" : {
"intervall" : [ ] //Poll
}
"connect" : [ ] // TODO: Relation to URL in Link <map>?
},
}
4.3. Secondary Servers and Mapping of Resources
[[anchor17: Details to be done.]]
5. Security Considerations
All the considerations of [OOBENC] and [SCD] apply.
A resource map can be used to cause the client to request malicious
content or perform DoS attacks on a victim secondary server. Clients
MUST verify the identity of server providing the Resource Map.
In the case the resource map is delivered as a separate Web resource,
the client MUST verify that the server providing the resource map
belong to the same authority as the primary server.
The secondary server SHOULD take actions to detect and manage request
loops caused by erroneous request from a client.
[[anchor19: TODO: Using tokens for access control to secondary.]]
[[anchor20: Issue: A resource map attribute that is applicable for a
set of resources may open up for mixed attacker-controlled data and
secrets.]]
6. IANA Considerations
This document currently has no actions for IANA.
7. References
Eriksson, et al. Expires May 4, 2017 [Page 9]
Internet-Draft Resource Maps October 2016
7.1. Normative References
[OOBENC] Reschke, J. and S. Loreto, "'Out-Of-Band' Content Coding
for HTTP", draft-reschke-http-oob-09 (work in progress),
October 2016.
[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>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/
RFC5988, October 2010,
<http://www.rfc-editor.org/info/rfc5988>.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
March 2014, <http://www.rfc-editor.org/info/rfc7159>.
7.2. Informative References
[BC] Thomson, M., Eriksson, G., and C. Holmberg, "Caching
Secure HTTP Content using Blind Caches",
draft-thomson-http-bc-01 (work in progress), October 2016.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/
RFC6570, March 2012,
<http://www.rfc-editor.org/info/rfc6570>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol version 2", RFC 7540, DOI 10.17487/
RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>.
[SCD] Thomson, M., Eriksson, G., and C. Holmberg, "An
Architecture for Secure Content Delegation using HTTP",
draft-thomson-http-scd-02 (work in progress),
October 2016.
URIs
[1] <mailto:ietf-http-wg@w3.org>
[2] <mailto:ietf-http-wg-request@w3.org?subject=subscribe>
Eriksson, et al. Expires May 4, 2017 [Page 10]
Internet-Draft Resource Maps October 2016
Appendix A. Multiple Secondary Servers
A primary server can provide multiple secondary servers for
retrieving a resource or set of resources.
A Resource Map for the case when resources on
"https://origin.example.com:8080" are mapped to two different
secondary servers:
{
"secondary-servers": {
"server1": {
"name": "blind cache 1",
"address": "bc.example.com",
"protocol": "https",
"port": 8083,
"description": "Some text for debugging"
},
"server2": {
"name": "blind cache 2",
"address": "bc2.example.com",
"protocol": "https",
"port": 8082
}
},
"resources": [
{
"resource-origin": "/ex_jsl.js",
"mapped-path":
"/origin.example.com%3A8080/j39jl3jaac/29jfnf0f",
"attributes": {
"Content-Type": "application/javascript",
"Content-Encoding": "aesgcm",
"MI": ".....",
"Crypto-Key": "....."
},
"mapped": [
{
"server": "server1",
"attributes": {
"Max-Age": 1800
}
},
{
"server": "server2",
"attributes": {
"Max-Age": 1800
Eriksson, et al. Expires May 4, 2017 [Page 11]
Internet-Draft Resource Maps October 2016
}
}
]
},
{
"resource-origin": "/another_resource.txt",
"mapped-path":
"/origin.example.com%3A8080/i39jfu2/1njknbs3",
"attributes": {
"Content-Type": "text/plain",
"Content-Encoding": "aesgcm",
"MI": ".....",
"Crypto-Key": "....."
},
"mapped": [
{
"server": "server2",
"attributes": {
"Max-Age": 1800
}
}
]
}
]
}
[[anchor25: in the above example, why does resource-origin include
scheme/host/port?]]
Appendix B. Change Log (To be removed before publication as RFC
Nothing yet.
Authors' Addresses
Goran AP Eriksson
Ericsson
Farogatan 6
Stockholm 16480
Sweden
Email: goran.ap.eriksson@ericsson.com
Eriksson, et al. Expires May 4, 2017 [Page 12]
Internet-Draft Resource Maps October 2016
Christer Holmberg
Ericsson
Email: christer.holmberg@ericsson.com
Zaheduzzaman Sarker
Ericsson
Email: zaheduzzaman.sarker@ericsson.com
Julian F. Reschke
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Eriksson, et al. Expires May 4, 2017 [Page 13]