idnits 2.17.1 draft-ahlgren-icnrg-netinf-cache-control-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3722 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Ahlgren, Ed. 3 Internet-Draft SICS 4 Intended status: Experimental B. Ohlman 5 Expires: August 18, 2014 Ericsson 6 February 14, 2014 8 NetInf Protocol Extensions for Cache Control 9 draft-ahlgren-icnrg-netinf-cache-control-00 11 Abstract 13 This document defines NetInf protocol extensions for controlling 14 caching behaviour. This includes bypassing caches, asking to not 15 return data, setting expiration time for objects, and marking objects 16 as non-cacheable. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 18, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Fromorigin extension for NetInf GET . . . . . . . . . . . . . 3 51 2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Nodata extension for NetInf GET . . . . . . . . . . . . . . . 4 54 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Expires NDO metadata . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Nocache NDO metadata . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Applications . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. NetInf ping . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.2. Dynamically generated data . . . . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 [[Text in double square brackets (like this) is commentary.]] 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119. [RFC2119] 78 Syntax definitions in this memo are specified according to ABNF 79 [RFC5234]. 81 This document describes extensions to the NetInf protocol 82 [I-D.kutscher-icnrg-netinf-proto] for controlling the object caching 83 behaviour from client requests (NetInf GET) and by publishers (NetInf 84 PUBLISH). 86 The extensions have several uses. For example, they enable a 87 publisher to provide dynamic data that is recomputed at certain 88 intervals. To be useful, the object name must be able to handle 89 dynamic data. The extensions also enable the implementation of a 90 NetInf counterpart to the IP program "ping". 92 [[Ideally, the extensions in this specification should be defined 93 independently of NetInf convergence layer (CL), but that currently 94 seems impossible.]] 96 2. Fromorigin extension for NetInf GET 98 "Fromorigin" is an extension parameter for the NetInf protocol 99 message GET. The latter is defined in Section 5.1 of the NetInf 100 protocol specification [I-D.kutscher-icnrg-netinf-proto]. The 101 purpose of the parameter is to enable a client to ask for an NDO to 102 be served from an origin server, and thus that the NDO is not served 103 from a NetInf cache. The concept of an "origin server" for an NDO 104 needs to be defined more precisely, but the intention is that this is 105 a server that has received and accepted a NetInf PUBLISH message for 106 the NDO with a so called "full put", that is, including the actual 107 NDO content data, or that it is a server that makes the NDO 108 available, for instance by PUBLISH:ing the existence of the NDO to a 109 NetInf name resolution server. 111 2.1. Syntax 113 The "fromorigin" parameter MUST be encoded in a json key-value field 114 named "fromorigin" in the "ext" parameter of the GET message. Its 115 data type MUST be boolean with the following interpretation of the 116 values: 118 true The client issuing the GET is requesting that the named NDO be 119 served from an origin server (and thus not from a cache). 121 false The client issuing the GET is not requesting any special 122 processing. The NDO can be served from a cache or origin server. 123 This is the normal, default, case when the parameter is not 124 present in the GET message. 126 An example is shown in Figure 1. 128 ext = { "fromorigin": true } 130 Figure 1: Example fromorigin parameter 132 2.2. Processing 134 A NetInf node that receives a GET message with the "fromorigin" 135 parameter set to true, SHOULD modify its processing of the request as 136 follows. 138 If the NetInf node has a copy of the NDO named in the GET message, 139 but it is not an origin server for the NDO, it SHOULD ignore that 140 copy and proceed with any other processing of the GET request, 141 including forwarding to another node. 143 This extension opens up a possibility for a DDOS attack which the 144 publisher of the data has no control over. See further discussion in 145 Section 7. 147 3. Nodata extension for NetInf GET 149 "Nodata" is an extension parameter for the NetInf protocol message 150 GET. The latter is defined in Section 5.1 of the NetInf protocol 151 specification [I-D.kutscher-icnrg-netinf-proto]. The purpose of the 152 parameter is to enable a client to check whether an NDO is available 153 without receiving a copy of the NDO. 155 3.1. Syntax 157 The "nodata" parameter MUST be encoded in a json key-value field 158 named "nodata" in the "ext" parameter of the GET message. Its data 159 type MUST be boolean with the following interpretation of the values: 161 true The client issuing the GET is requesting that the NDO data is 162 not sent back in response, but rather just a status response 163 indicating whether the NDO exists. 165 false The client issuing the GET is not requesting any special 166 processing. This is the normal, default, case when the parameter 167 is not present in the GET message. 169 An example is shown in Figure 2. 171 ext = { "nodata": true } 173 Figure 2: Example nodata parameter 175 3.2. Processing 177 A NetInf node that receives a GET message with the "nodata" parameter 178 set to true, MUST modify its processing of the request as follows. 180 If the NetInf node has a copy of the NDO named in the GET message, it 181 MUST NOT include the NDO data in the GET-RESP message, but rather 182 only include URI locators as specified in Section 5.1 of 183 [I-D.kutscher-icnrg-netinf-proto]. 185 4. Expires NDO metadata 187 "Expires" is an NDO metadata field that can be specified by the 188 publisher of an NDO. "Expires" contains the time delta from current, 189 publishing, time to when the publisher regards the NDO as expired, 190 and thus wants any cached copies of the NDO to be regarded as 191 invalid. The metadata is stored together with the actual NDO data as 192 discussed in Section 5.2 of [I-D.kutscher-icnrg-netinf-proto]. 194 The "expires" NDO metadata is specified by publishers in the PUBLISH 195 message as part of the "meta" field in the json-encoded "ext" 196 parameter. When the NDO is returned in a GET-RESP message, the 197 "expires" metadata is supplied as part of the affiliated data to the 198 NDO in the application/json MIME part. 200 There are multiple issues with this kind of parameter. A time delta, 201 as currently specified, depends on that nodes can decrement the value 202 with reasonable accuracy. An alternative or complement would be to 203 add a parameter with absolute expiration time. That solution depends 204 on reasonable accurate timekeeping. Another alternative is to add 205 the publishing time. The exact solution is for further study and 206 experimentation. 208 4.1. Syntax 210 The "expires" NDO metadata MUST be specified as an json key-value 211 field with the name "expires". Its data type MUST be of type 212 integer. It specifies the time delta as number of seconds. 214 [[Perhaps use RFC3339 format instead? Durations in its Appendix A 215 from ISO8601?]] 217 In the NetInf PUBLISH message, the "expires" key-value field is 218 contained in a "meta" key-value field in the "ext" parameter as 219 specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto]. An 220 example is shown in Figure 3. 222 ext = { "meta": { "expires": 3600 } } 224 Figure 3: Example expires metadata in PUBLISH message 226 In the NetInf GET-RESP message, the "expires" key-value field is 227 contained in the application/json component of the message body as 228 part of the "metadata" key-value field as specified in Section 6.1 of 229 [I-D.kutscher-icnrg-netinf-proto]. 231 4.2. Processing 232 A NetInf node receiving a NetInf GET message for an NDO that is 233 present in its cache SHOULD check the NDO's metadata for an "expires" 234 key-value field. The node SHOULD to the best of its ability 235 determine whether the expiration time has passed. If the expiration 236 time has passed, it SHOULD disregard the cached copy and continue 237 with any other processing of the GET message, including the 238 possibility to forward the message to another node. 240 A NetInf node receiving a NetInf PUBLISH message containing object 241 data ("full-ndo-flag") and the "expires" key-value field in the NDO 242 metadata, SHOULD keep the key-value field with the NDO as affiliated 243 data. This is normal processing as specified in Section 6.1 of 244 [I-D.kutscher-icnrg-netinf-proto]. 246 A NetInf node responding with a NetInf GET-RESP containing the NDO 247 object octets, SHOULD include any "expires" key-value field metadata 248 associated with the NDO in the application/json body part. This is 249 also normal processing as specified in Section 6.1 of 250 [I-D.kutscher-icnrg-netinf-proto]. 252 A NetInf node receiving a NetInf GET-RESP message containing the NDO 253 object octets, SHOULD keep any "expires" key-value field metadata 254 associated with the NDO. This applies both if the node forwards the 255 GET-RESP back to another requester, and if the node decides to keep 256 this NDO in its local cache. This is normal processing as specified 257 in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto]. 259 5. Nocache NDO metadata 261 "Nocache" is an NDO metadata field that can be specified by the 262 publisher of an NDO. "Nocache" is a boolean value that when set to 263 true, inhibits caching of the NDO by NetInf nodes. The metadata is 264 stored together with the actual NDO data as discussed in Section 5.2 265 of [I-D.kutscher-icnrg-netinf-proto]. 267 The "nocache" NDO metadata is specified by publishers in the PUBLISH 268 message as part of the "meta" field in the json-encoded "ext" 269 parameter. When the NDO is returned in a GET-RESP message, the 270 "nocache" metadata is supplied as part of the affiliated data to the 271 NDO in the application/json MIME part. 273 5.1. Syntax 275 The "nocache" NDO metadata MUST be specified as an json key-value 276 field with the name "nocache". Its data type MUST be of type 277 boolean. When set to "true", the publisher indicates that this NDO 278 should not be cached. When set to "false", the default if not 279 present, indicates that NetInf nodes may cache the NDO object data. 281 In the NetInf PUBLISH message, the "nocache" key-value field is 282 contained in a "meta" key-value field in the "ext" parameter as 283 specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto]. An 284 example is shown in Figure 4. 286 ext = { "meta": { "nocache": true } } 288 Figure 4: Example nocache metadata in PUBLISH message 290 In the NetInf GET-RESP message, the "nocache" key-value field is 291 contained in the application/json component of the message body as 292 part of the "metadata" key-value field as specified in Section 6.1 of 293 [I-D.kutscher-icnrg-netinf-proto]. 295 5.2. Processing 297 A NetInf node receiving a NetInf PUBLISH message containing object 298 data ("full-ndo-flag") and the "nocache" key-value field in the NDO 299 metadata, MUST keep the key-value field with the NDO as affiliated 300 data. This is normal processing as specified in Section 6.1 of 301 [I-D.kutscher-icnrg-netinf-proto]. 303 A NetInf node receiving a NetInf GET-RESP message containing an NDO 304 with the "nocache" key-value field set to true, MUST NOT keep a copy 305 of the NDO in its cache. 307 A NetInf node responding with a NetInf GET-RESP message containing 308 the NDO object octets, MUST include any "nocache" key-value field 309 metadata associated with the NDO in the application/json body part. 310 This is also normal processing as specified in Section 6.1 of 311 [I-D.kutscher-icnrg-netinf-proto]. 313 6. Applications 315 The extensions described in this document can be used for several 316 purposes. Some of them are described in this section. 318 6.1. NetInf ping 320 A kind of "NetInf ping" can be implemented, with which the 321 reachability of a certain NDO can be checked. A client issues a 322 NetInf GET request with the "nodata" extension. If a valid response 323 is received, the NDO is reachable. The request can be combined with 324 the "fromorigin" extension, so that the request is not satisfied when 325 a cached copy is encountered, but rather forwarded to an origin 326 publisher for the NDO. The client can with this combination check 327 the reachability of the NDO at the publisher or origin server. 329 6.2. Dynamically generated data 331 Two kinds of dynamically generated data can be created by publishers 332 using the "expires" and "nocache" NDO metadata. To be useful, 333 dynamically generated data should not use names including the content 334 hash in the name, since new, different, data then necessarily results 335 in a new name. A scheme that ensures name-data integrity using 336 signatures is rather needed. 338 Using "nocache" means that all requests for that particular NDO name 339 will reach the origin publisher, which then dynamically can create 340 the data when the request arrives. 342 Using "expires" means that the NDO can be cached for a certain time 343 duration. The publisher can then regularly update the NDO with new 344 data. 346 7. Security Considerations 348 fromorgin - opens for dos attacks on origin servers (especially when 349 not together with nodata) 351 [[This section needs much more work!]] 353 8. Acknowledgements 355 Ericsson and SICS colleagues in Center for Networked Systems at SICS, 356 the EFRAIM project, and partners in the former EU FP7 project SAIL. 358 9. Normative References 360 [I-D.kutscher-icnrg-netinf-proto] 361 Kutscher, D., Farrell, S., and E. Davies, "The NetInf 362 Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in 363 progress), February 2013. 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 369 Specifications: ABNF", STD 68, RFC 5234, January 2008. 371 Authors' Addresses 372 Bengt Ahlgren (editor) 373 SICS 374 Isafjordsgatan 22 375 Kista SE-16429 376 Sweden 378 Email: bengta@sics.se 380 Boerje Ohlman 381 Ericsson 382 Faeroegatan 6 383 Kista SE-16429 384 Sweden 386 Email: borje.ohlman@ericsson.com