Network Working Group | B. Ahlgren, Ed. |
Internet-Draft | SICS |
Intended status: Experimental | B. Ohlman |
Expires: August 18, 2014 | Ericsson |
February 14, 2014 |
NetInf Protocol Extensions for Cache Control
draft-ahlgren-icnrg-netinf-cache-control-00
This document defines NetInf protocol extensions for controlling caching behaviour. This includes bypassing caches, asking to not return data, setting expiration time for objects, and marking objects as non-cacheable.
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 August 18, 2014.
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.
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 RFC 2119. [RFC2119]
Syntax definitions in this memo are specified according to ABNF [RFC5234].
This document describes extensions to the NetInf protocol [I-D.kutscher-icnrg-netinf-proto] for controlling the object caching behaviour from client requests (NetInf GET) and by publishers (NetInf PUBLISH).
The extensions have several uses. For example, they enable a publisher to provide dynamic data that is recomputed at certain intervals. To be useful, the object name must be able to handle dynamic data. The extensions also enable the implementation of a NetInf counterpart to the IP program "ping".
"Fromorigin" is an extension parameter for the NetInf protocol message GET. The latter is defined in Section 5.1 of the NetInf protocol specification [I-D.kutscher-icnrg-netinf-proto]. The purpose of the parameter is to enable a client to ask for an NDO to be served from an origin server, and thus that the NDO is not served from a NetInf cache. The concept of an "origin server" for an NDO needs to be defined more precisely, but the intention is that this is a server that has received and accepted a NetInf PUBLISH message for the NDO with a so called "full put", that is, including the actual NDO content data, or that it is a server that makes the NDO available, for instance by PUBLISH:ing the existence of the NDO to a NetInf name resolution server.
The "fromorigin" parameter MUST be encoded in a json key-value field named "fromorigin" in the "ext" parameter of the GET message. Its data type MUST be boolean with the following interpretation of the values:
An example is shown in Figure 1.
ext = { "fromorigin": true }
Figure 1: Example fromorigin parameter
A NetInf node that receives a GET message with the "fromorigin" parameter set to true, SHOULD modify its processing of the request as follows.
If the NetInf node has a copy of the NDO named in the GET message, but it is not an origin server for the NDO, it SHOULD ignore that copy and proceed with any other processing of the GET request, including forwarding to another node.
This extension opens up a possibility for a DDOS attack which the publisher of the data has no control over. See further discussion in Section 7.
"Nodata" is an extension parameter for the NetInf protocol message GET. The latter is defined in Section 5.1 of the NetInf protocol specification [I-D.kutscher-icnrg-netinf-proto]. The purpose of the parameter is to enable a client to check whether an NDO is available without receiving a copy of the NDO.
The "nodata" parameter MUST be encoded in a json key-value field named "nodata" in the "ext" parameter of the GET message. Its data type MUST be boolean with the following interpretation of the values:
An example is shown in Figure 2.
ext = { "nodata": true }
Figure 2: Example nodata parameter
A NetInf node that receives a GET message with the "nodata" parameter set to true, MUST modify its processing of the request as follows.
If the NetInf node has a copy of the NDO named in the GET message, it MUST NOT include the NDO data in the GET-RESP message, but rather only include URI locators as specified in Section 5.1 of [I-D.kutscher-icnrg-netinf-proto].
"Expires" is an NDO metadata field that can be specified by the publisher of an NDO. "Expires" contains the time delta from current, publishing, time to when the publisher regards the NDO as expired, and thus wants any cached copies of the NDO to be regarded as invalid. The metadata is stored together with the actual NDO data as discussed in Section 5.2 of [I-D.kutscher-icnrg-netinf-proto].
The "expires" NDO metadata is specified by publishers in the PUBLISH message as part of the "meta" field in the json-encoded "ext" parameter. When the NDO is returned in a GET-RESP message, the "expires" metadata is supplied as part of the affiliated data to the NDO in the application/json MIME part.
There are multiple issues with this kind of parameter. A time delta, as currently specified, depends on that nodes can decrement the value with reasonable accuracy. An alternative or complement would be to add a parameter with absolute expiration time. That solution depends on reasonable accurate timekeeping. Another alternative is to add the publishing time. The exact solution is for further study and experimentation.
The "expires" NDO metadata MUST be specified as an json key-value field with the name "expires". Its data type MUST be of type integer. It specifies the time delta as number of seconds.
In the NetInf PUBLISH message, the "expires" key-value field is contained in a "meta" key-value field in the "ext" parameter as specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto]. An example is shown in Figure 3.
ext = { "meta": { "expires": 3600 } }
Figure 3: Example expires metadata in PUBLISH message
In the NetInf GET-RESP message, the "expires" key-value field is contained in the application/json component of the message body as part of the "metadata" key-value field as specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto].
A NetInf node receiving a NetInf GET message for an NDO that is present in its cache SHOULD check the NDO's metadata for an "expires" key-value field. The node SHOULD to the best of its ability determine whether the expiration time has passed. If the expiration time has passed, it SHOULD disregard the cached copy and continue with any other processing of the GET message, including the possibility to forward the message to another node.
A NetInf node receiving a NetInf PUBLISH message containing object data ("full-ndo-flag") and the "expires" key-value field in the NDO metadata, SHOULD keep the key-value field with the NDO as affiliated data. This is normal processing as specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto].
A NetInf node responding with a NetInf GET-RESP containing the NDO object octets, SHOULD include any "expires" key-value field metadata associated with the NDO in the application/json body part. This is also normal processing as specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto].
A NetInf node receiving a NetInf GET-RESP message containing the NDO object octets, SHOULD keep any "expires" key-value field metadata associated with the NDO. This applies both if the node forwards the GET-RESP back to another requester, and if the node decides to keep this NDO in its local cache. This is normal processing as specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto].
"Nocache" is an NDO metadata field that can be specified by the publisher of an NDO. "Nocache" is a boolean value that when set to true, inhibits caching of the NDO by NetInf nodes. The metadata is stored together with the actual NDO data as discussed in Section 5.2 of [I-D.kutscher-icnrg-netinf-proto].
The "nocache" NDO metadata is specified by publishers in the PUBLISH message as part of the "meta" field in the json-encoded "ext" parameter. When the NDO is returned in a GET-RESP message, the "nocache" metadata is supplied as part of the affiliated data to the NDO in the application/json MIME part.
The "nocache" NDO metadata MUST be specified as an json key-value field with the name "nocache". Its data type MUST be of type boolean. When set to "true", the publisher indicates that this NDO should not be cached. When set to "false", the default if not present, indicates that NetInf nodes may cache the NDO object data.
In the NetInf PUBLISH message, the "nocache" key-value field is contained in a "meta" key-value field in the "ext" parameter as specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto]. An example is shown in Figure 4.
ext = { "meta": { "nocache": true } }
Figure 4: Example nocache metadata in PUBLISH message
In the NetInf GET-RESP message, the "nocache" key-value field is contained in the application/json component of the message body as part of the "metadata" key-value field as specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto].
A NetInf node receiving a NetInf PUBLISH message containing object data ("full-ndo-flag") and the "nocache" key-value field in the NDO metadata, MUST keep the key-value field with the NDO as affiliated data. This is normal processing as specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto].
A NetInf node receiving a NetInf GET-RESP message containing an NDO with the "nocache" key-value field set to true, MUST NOT keep a copy of the NDO in its cache.
A NetInf node responding with a NetInf GET-RESP message containing the NDO object octets, MUST include any "nocache" key-value field metadata associated with the NDO in the application/json body part. This is also normal processing as specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto].
The extensions described in this document can be used for several purposes. Some of them are described in this section.
A kind of "NetInf ping" can be implemented, with which the reachability of a certain NDO can be checked. A client issues a NetInf GET request with the "nodata" extension. If a valid response is received, the NDO is reachable. The request can be combined with the "fromorigin" extension, so that the request is not satisfied when a cached copy is encountered, but rather forwarded to an origin publisher for the NDO. The client can with this combination check the reachability of the NDO at the publisher or origin server.
Two kinds of dynamically generated data can be created by publishers using the "expires" and "nocache" NDO metadata. To be useful, dynamically generated data should not use names including the content hash in the name, since new, different, data then necessarily results in a new name. A scheme that ensures name-data integrity using signatures is rather needed.
Using "nocache" means that all requests for that particular NDO name will reach the origin publisher, which then dynamically can create the data when the request arrives.
Using "expires" means that the NDO can be cached for a certain time duration. The publisher can then regularly update the NDO with new data.
fromorgin - opens for dos attacks on origin servers (especially when not together with nodata)
Ericsson and SICS colleagues in Center for Networked Systems at SICS, the EFRAIM project, and partners in the former EU FP7 project SAIL.
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
[RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. |
[I-D.kutscher-icnrg-netinf-proto] | Kutscher, D., Farrell, S. and E. Davies, "The NetInf Protocol", Internet-Draft draft-kutscher-icnrg-netinf-proto-01, February 2013. |