idnits 2.17.1 draft-ietf-core-http-mapping-02.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 : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2013) is 3847 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '251557' on line 757 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-12 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-24 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-16 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group A. Castellani 3 Internet-Draft University of Padova 4 Intended status: Informational S. Loreto 5 Expires: April 15, 2014 Ericsson 6 A. Rahman 7 InterDigital Communications, LLC 8 T. Fossati 9 KoanLogic 10 E. Dijk 11 Philips Research 12 October 12, 2013 14 Guidelines for HTTP-CoAP Mapping Implementations 15 draft-ietf-core-http-mapping-02 17 Abstract 19 This draft provides reference information for HTTP-CoAP protocol 20 translation proxy implementors, focusing primarily on the reverse 21 proxy case. It details deployment options, defines a safe method for 22 URI mapping, and provides a set of guidelines and considerations 23 related to protocol translation. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 15, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Cross-Protocol Usage of URIs . . . . . . . . . . . . . . . . 4 62 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Default HTTP to CoAP URI Mapping . . . . . . . . . . . . . . 5 64 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 65 5.2. URI Mapping Template . . . . . . . . . . . . . . . . . . 6 66 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. HTTP-CoAP Reverse Proxy . . . . . . . . . . . . . . . . . . . 7 68 6.1. Proxy Placement . . . . . . . . . . . . . . . . . . . . . 8 69 6.2. Response Code Translations . . . . . . . . . . . . . . . 9 70 6.3. Media Type Translations . . . . . . . . . . . . . . . . . 11 71 6.4. Caching and Congestion Control . . . . . . . . . . . . . 12 72 6.5. Cache Refresh via Observe . . . . . . . . . . . . . . . . 12 73 6.6. Use of CoAP Blockwise Transfer . . . . . . . . . . . . . 13 74 6.7. Security Translation . . . . . . . . . . . . . . . . . . 14 75 6.8. Other guidelines . . . . . . . . . . . . . . . . . . . . 14 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 8.1. Traffic overflow . . . . . . . . . . . . . . . . . . . . 15 79 8.2. Handling Secured Exchanges . . . . . . . . . . . . . . . 16 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 83 10.2. Informative References . . . . . . . . . . . . . . . . . 18 84 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Introduction 89 CoAP [I-D.ietf-core-coap] has been designed with the twofold aim to 90 be an application protocol specialized for constrained environments 91 and to be easily used in REST architectures such as the Web. The 92 latter goal has led to define CoAP to easily interoperate with HTTP 93 [RFC2616] through an intermediary proxy which performs cross-protocol 94 conversion. 96 Section 10 of [I-D.ietf-core-coap] describes the fundamentals of the 97 CoAP-to-HTTP and the HTTP-to-CoAP cross-protocol mapping process. 98 However, implementing such a cross-protocol proxy can be complex, and 99 many details regarding its internal procedures and design choices 100 require further elaboration. Therefore a first goal of this document 101 is to provide more detailed information to proxy designers and 102 implementers, to help implement proxies that correctly inter-work 103 with other CoAP and HTTP client/server implementations that adhere to 104 the HTTP and CoAP specifications. 106 The second goal of this informational document is to define a 107 consistent set of guidelines that a HTTP-to-CoAP proxy implementation 108 MAY adhere to. The main reason of adhering to such guidelines is to 109 reduce variation between proxy implementations, thereby increasing 110 interoperability. (As an example use case, a proxy conforming to 111 these guidelines made by vendor A can be easily replaced by a proxy 112 from vendor B that also conforms to the guidelines.) 114 This draft is organized as follows: 116 o Section 2 describes terminology to identify proxy types, mapping 117 approaches and proxy deployments; 119 o Section 3 discusses how URIs refer to resources independent of 120 access protocols; 122 o Section 4 briefly lists use cases in which HTTP clients need to 123 contact CoAP servers; 125 o Section 5 introduces a default HTTP-to-CoAP URI mapping syntax; 127 o Section 6 analyzes the mapping that allows HTTP clients to contact 128 CoAP servers; 130 o Section 8 discusses possible security impact related to HTTP-CoAP 131 cross-protocol mapping. 133 2. Terminology 135 This document assumes readers are familiar with the terms Reverse 136 Proxy as defined in [I-D.ietf-httpbis-p1-messaging] and Interception 137 Proxy as defined in [RFC3040]. In addition, the following terms are 138 defined: 140 Cross-Protocol Proxy (or Cross Proxy): is a proxy performing a cross- 141 protocol mapping, in the context of this document a HTTP-CoAP (HC) 142 mapping. A Cross-Protocol Proxy can behave as a Forward Proxy, 143 Reverse Proxy or Interception Proxy. Note: In this document we focus 144 on the Reverse Proxy mode of the Cross-Protocol Proxy. 146 Forward Proxy: a message forwarding agent that is selected by the 147 client, usually via local configuration rules, to receive requests 148 for some type(s) of absolute URI and to attempt to satisfy those 149 requests via translation to the protocol indicated by the absolute 150 URI. The user decides (is willing to) use the proxy as the 151 forwarding/dereferencing agent for a predefined subset of the URI 152 space. 154 Reverse Proxy: a receiving agent that acts as a layer above some 155 other server(s) and translates the received requests to the 156 underlying server's protocol. It behaves as an origin (HTTP) server 157 on its connection towards the (HTTP) client and as a (CoAP) client on 158 its connection towards the (CoAP) origin server. The (HTTP) client 159 uses the "origin-form" [I-D.ietf-httpbis-p1-messaging] as a request- 160 target URI. 162 Reverse and Forward proxies are technically very similar, with main 163 differences being that the former appears to a client as an origin 164 server while the latter does not, and that clients may be unaware 165 they are communicating with a proxy. 167 Placement terms: a server-side (SS) proxy is placed in the same 168 network domain as the server; conversely a client-side (CS) proxy is 169 in the same network domain as the client. In any other case than SS 170 or CS, the proxy is said to be External (E). 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in 175 [RFC2119]. 177 3. Cross-Protocol Usage of URIs 179 A Uniform Resource Identifier (URI) provides a simple and extensible 180 method for identifying a resource. It enables uniform identification 181 of resources via a separately defined extensible set of naming 182 schemes [RFC3986]. 184 URIs are formed of at least three components: scheme, authority and 185 path. The scheme often corresponds to the protocol used to access 186 the resource. However, as noted in Section 1.2.2 of [RFC3986] the 187 scheme does not imply that a particular protocol is used to access 188 the resource. So, we can define the same resource to be accessible 189 by different protocols i.e. the resource can have cross-protocol URIs 190 referring to it. 192 HTTP clients typically only support 'http' and 'https' schemes. 193 Therefore, they cannot directly access CoAP servers (which support 194 'coap' and/or 'coaps'). In this situation, communication is enabled 195 by a Cross-Protocol Proxy, as shown in Figure 1, supporting URI 196 mapping features. Such features are discussed in Section 5. 198 4. Use Cases 200 To illustrate in which situations HTTP to CoAP request mapping may be 201 used, three use cases are briefly described. 203 1. Smartphone and home sensor: A smartphone, when at home, can 204 perform 'coap' requests directly to a home sensor via WiFi. When the 205 smartphone is away from home, the same request is done by an 206 authenticated 'https' request over an external IP network to the home 207 router. The home router contains a HTTP-CoAP proxy. 209 2. Legacy building control application without CoAP: A building 210 control application can use HTTP, but not CoAP. It checks the status 211 of sensors or actuators via a HTTP-CoAP proxy. 213 3. Making sensor data available to 3rd parties: For demonstration or 214 public interest purposes, a HTTP-CoAP proxy may be configured to 215 expose the contents of a sensor to the world via the web (HTTP and/or 216 HTTPS). The sensor can only handle secure 'coaps' requests, 217 therefore the proxy is configured to translate any request to a 218 'coaps' secured request. The proxy is furthermore configured to only 219 pass through GET requests. 221 5. Default HTTP to CoAP URI Mapping 223 5.1. Introduction 225 This section defines a default URI mapping function that is 226 RECOMMENDED to be implemented and activated by default in a HTTP-to- 227 CoAP proxy, unless there are reasons (e.g. application-specific) to 228 use other mapping function(s). 230 From a high level viewpoint, the URI mapping is implemented in a HTTP 231 client by appending the CoAP URI to a HTTP proxy base URI. For 232 example: a base URI may be http://p.example.com/.well-known/core/ and 233 the CoAP URI may be coap://s.coap.example.com/foo. The mapping then 234 embeds the COAP URI into a HTTP URI by appending it, as follows: 236 http://p.example.com/.well-known/core/coap://s.coap.example.com/foo 238 A formal definition of this function and more examples are provided 239 below. 241 5.2. URI Mapping Template 243 The URI template is one of the following two expressions, using the 244 notation of [RFC6570]. 246 o {+proxy-origin}/.well-known/core/{scheme}://{+authority}{+path- 247 absolute} 249 o {+proxy-origin}/.well-known/core/{scheme}://{+authority}{+path- 250 absolute}{+?query} 252 Where: 254 o proxy-origin identifies the proxy HTTP side as usual scheme "://" 255 authority; 257 o scheme is the scheme of the embedded CoAP URI, either 'coap' or 258 'coaps'; 260 o authority is the CoAP URI authority. If the host is in 261 IPv6address format, then the '[' and ']' characters MUST be 262 percent-encoded, in order to comply with the syntax defined in 263 Section 3.3. of [RFC3986] for a URI path segment; 265 o path-absolute (defined by [RFC3986]) is the absolute CoAP URI 266 path; 268 o query (defined by [RFC3986]) is the optional query component of 269 the CoAP URI. 271 5.3. Examples 273 Each example below shows a HTTP URI that is used by a HTTP client to 274 make a request to a HTTP-CoAP proxy http://p.example.com. The CoAP 275 URI shown below is the URI that is extracted from the HTTP URI by the 276 proxy, using the default URI mapping scheme introduced earlier. 278 Example 1: 280 o http://p.example.com/.well-known/core/coap:// 281 s.coap.example.com:4567/foo/bar?a=3 283 o coap://s.coap.example.com:4567/foo/bar?a=3 284 Example 2: 286 o http://p.example.com/.well-known/core/coap:// 287 %5B2001:db8::1%5D:4567/foo/bar?a=3 289 o coap://[2001:db8::1]:4567/foo/bar?a=3 291 Example 3: 293 o http://p.example.com/.well-known/core/coaps://s.coap.example.com/ 294 foo(bar)?a=3 296 o coaps://s.coap.example.com/foo(bar)?a=3 298 Example 4: 300 o http://p.example.com/.well-known/core/coap://1.2.3.4:4567/foo/ 301 bar?a=3&key=value 303 o coap://1.2.3.4:4567/foo/bar?a=3&key=value 305 Example 5: 307 o http://p.example.com/.well-known/core/coap://%5B2001:db8::1%5D/ 308 foo%5Bbar%5D?a=3/5/7 310 o coap://[2001:db8::1]/foo%5Bbar%5D?a=3/5/7 312 6. HTTP-CoAP Reverse Proxy 314 A HTTP-CoAP Reverse Cross-Protocol Proxy is accessed by web clients 315 only supporting HTTP, and handles their requests by mapping these to 316 CoAP requests, which are forwarded to CoAP servers; and mapping back 317 the received CoAP responses to HTTP. This mechanism is transparent 318 to the client, which may assume that it is communicating with the 319 intended target HTTP server. In other words, the client accesses the 320 proxy as an origin server using the "origin-form" 321 [I-D.ietf-httpbis-p1-messaging] as a Request Target. 323 Normative requirements on the translation of HTTP requests to CoAP 324 and of the CoAP responses back to HTTP responses are defined in 325 Section 10.2 of [I-D.ietf-core-coap]. However, that section only 326 considers the case of a HTTP-CoAP Forward Cross-Protocol Proxy in 327 which a client explicitly indicates it targets a request to a CoAP 328 server, and does not cover all aspects of proxy implementation in 329 detail. The present section provides guidelines and more details for 330 the implementation of a Reverse Cross-Protocol Proxy, which MAY be 331 followed in addition to the normative requirements. 333 Translation of unicast HTTP requests into multicast CoAP requests is 334 currently out of scope since in a reverse proxy scenario a HTTP 335 client typically expects to receive a single response, not multiple. 336 However a Cross-Protocol Proxy MAY include custom application- 337 specific functions to generate a multicast CoAP request based on a 338 unicast HTTP request and aggregate multiple CoAP responses into a 339 single HTTP response. 341 Note that the guidelines in this section also apply to an HTTP-CoAP 342 Intercepting Cross-Protocol Proxy. 344 6.1. Proxy Placement 346 Typically, a Cross-Protocol Proxy is located at the edge of the 347 constrained network. See Figure 1. The arguments supporting server- 348 side (SS) placement are the following: 350 Caching: Efficient caching requires that all request traffic to a 351 CoAP server is handled by the same proxy which receives HTTP 352 requests from multiple source locations. This maximally reduces 353 the load on (constrained) CoAP servers. 355 Multicast: To support CoAPs use of local-multicast functionality 356 available in a constrained network, the Cross-Protocol Proxy 357 requires a network interface directly attached to the constrained 358 network. 360 TCP/UDP: Translation between HTTP and CoAP requires also TCP/UDP 361 translation; TCP may be the preferred way for communicating with 362 the constrained network due to its reliability or due to 363 intermediate gateways configured to block UDP traffic. 365 Arguments against SS placement, in favor of client-side (CS), are: 367 Scalability: A solution where a single SS proxy has to manage 368 numerous open TCP/IP connections to a large number of HTTP clients 369 is not scalable. (Unless multiple SS proxies are employed with a 370 load-balancing mechanism, which adds complexity.) 372 +------+ 373 | | 374 | DNS | 375 | | 376 +------+ Constrained Network 377 -------------------- 378 / \ 379 / /-----\ /-----\ \ 381 / CoAP CoAP \ 382 / server server \ 383 || \-----/ \-----/ || 384 +------+ HTTP Request +----------+ || 385 |HTTP |------------------------>| HTTP-CoAP| Req /-----\ || 386 |Client| | Cross- |------->| CoAP || 387 | |<------------------------| Proxy |<-------|server || 388 +------+ HTTP Response +----------+ Resp \-----/ || 389 || || 390 || /-----\ || 391 || CoAP || 392 \ server / 393 \ \-----/ / 394 \ /-----\ / 395 \ CoAP / 396 \ server / 397 \ \-----/ / 398 ---------------- 400 Figure 1: Reverse Cross-Protocol Proxy Deployment Scenario 402 6.2. Response Code Translations 404 Table 1 defines all possible CoAP responses along with the HTTP 405 response to which each CoAP response SHOULD be translated. This 406 table complies with the Section 10.2 requirements of 407 [I-D.ietf-core-coap] and is intended to cover all possible cases. 408 Multiple appearances of a HTTP status code in the second column 409 indicates multiple equivalent HTTP responses are possible, depending 410 on the conditions cited in the Notes (third column). 412 +----------------------------+----------------------------+---------+ 413 | CoAP Response Code | HTTP Status Code | Notes | 414 +----------------------------+----------------------------+---------+ 415 | 2.01 Created | 201 Created | 1 | 416 | 2.02 Deleted | 200 OK | 2 | 417 | | 204 No Content | 2 | 418 | 2.03 Valid | 304 Not Modified | 3 | 419 | | 200 OK | 4 | 420 | 2.04 Changed | 200 OK | 2 | 421 | | 204 No Content | 2 | 422 | 2.05 Content | 200 OK | | 423 | 4.00 Bad Request | 400 Bad Request | | 424 | 4.01 Unauthorized | 400 Bad Request | 5 | 425 | 4.02 Bad Option | 400 Bad Request | 6 | 426 | 4.03 Forbidden | 403 Forbidden | | 427 | 4.04 Not Found | 404 Not Found | | 428 | 4.05 Method Not Allowed | 400 Bad Request | 7 | 429 | 4.06 Not Acceptable | 406 Not Acceptable | | 430 | 4.12 Precondition Failed | 412 Precondition Failed | | 431 | 4.13 Request Entity Too | 413 Request Repr. Too | | 432 | Large | Large | | 433 | 4.15 Unsupported Media | 415 Unsupported Media Type | | 434 | Type | | | 435 | 5.00 Internal Server Error | 500 Internal Server Error | | 436 | 5.01 Not Implemented | 501 Not Implemented | | 437 | 5.02 Bad Gateway | 502 Bad Gateway | | 438 | 5.03 Service Unavailable | 503 Service Unavailable | 8 | 439 | 5.04 Gateway Timeout | 504 Gateway Timeout | | 440 | 5.05 Proxying Not | 502 Bad Gateway | 9 | 441 | Supported | | | 442 +----------------------------+----------------------------+---------+ 444 Table 1: HTTP-CoAP Response Mapping 446 Notes: 448 1. A CoAP server may return an arbitrary format payload along with 449 this response. This payload SHOULD be returned as entity in the 450 HTTP 201 response. Section 7.3.2 of 451 [I-D.ietf-httpbis-p2-semantics] does not put any requirement on 452 the format of the payload. (In the past, [RFC2616] did.) 454 2. The HTTP code is 200 or 204 respectively for the case that a CoAP 455 server returns a payload or not. [I-D.ietf-httpbis-p2-semantics] 456 Section 5.3 requires code 200 in case a representation of the 457 action result is returned for DELETE, POST and PUT and code 204 458 if not. Hence, a proxy SHOULD transfer any CoAP payload 459 contained in a 2.02 response to the HTTP client in a 200 OK 460 response. 462 3. A CoAP 2.03 (Valid) response only (1) confirms that the request 463 ETag is valid and (2) provides a new Max-Age value. HTTP 304 464 (Not Modified) also updates some header fields of a stored 465 response. A non-caching proxy may not have enough information to 466 fill in the required values in the HTTP 304 (Not Modified) 467 response, so it may not be advisable for a non-caching proxy to 468 provoke the 2.03 (Valid) response by forwarding an ETag. A 469 caching proxy will fill the information out of the cache. 471 4. A 200 response to a CoAP 2.03 occurs only when the proxy is 472 caching and translated a HTTP request (without validation 473 request) to a CoAP request that includes validation, for 474 efficiency. The proxy receiving 2.03 updates the freshness of 475 the cached representation and returns the entire representation 476 to the HTTP client. 478 5. The HTTP code 401 Unauthorized MUST NOT be used, as long as in 479 CoAP there is no equivalent defined of the required WWW- 480 Authenticate header (Section 3.1 of [I-D.ietf-httpbis-p7-auth]). 482 6. In some cases a proxy receiving 4.02 may retry the request with 483 less CoAP Options in the hope that the server will understand the 484 newly formulated request. For example, if the proxy tried using 485 a Block Option which was not recognized by the CoAP server it may 486 retry without that Block Option. 488 7. The HTTP code "405 Method Not Allowed" MUST NOT be used since 489 CoAP does not provide enough information to determine a value for 490 the required "Allow" response-header field. 492 8. The value of the HTTP "Retry-After" response-header field is 493 taken from the value of the CoAP Max-Age Option, if present. 495 9. This CoAP response can only happen if the proxy itself is 496 configured to use a CoAP Forward Proxy to execute some, or all, 497 of its CoAP requests. 499 6.3. Media Type Translations 501 A Cross-Protocol Proxy translates a media type string, carried in a 502 HTTP Content-Type header in a request, to a CoAP Content-Format 503 Option with the equivalent numeric value. The media types supported 504 by CoAP are defined in the CoAP Content-Format Registry. Any HTTP 505 request with a Content-Type for which the proxy does not know an 506 equivalent CoAP Content-Format number, MUST lead to HTTP response 415 507 (Unsupported Media Type). 509 Also, a CoAP Content-Format value in a response is translated back to 510 the equivalent HTTP Content-Type. If a proxy receives a CoAP 511 Content-Format value that it does not recognize (e.g. because the 512 value is IANA-registered after the proxy software was deployed), and 513 is unable to look up the equivalent HTTP Content-Type on the fly, the 514 proxy SHOULD return an HTTP entity (payload) without Content-Type 515 header (complying to Section 3.1.1.5 of 516 [I-D.ietf-httpbis-p2-semantics]). 518 6.4. Caching and Congestion Control 520 A Cross-Protocol Proxy SHOULD limit the number of requests to CoAP 521 servers by responding, where applicable, with a cached representation 522 of the resource. 524 Duplicate idempotent pending requests by a Cross-Protocol Proxy to 525 the same CoAP resource SHOULD in general be avoided, by duplexing the 526 response to the requesting HTTP clients without duplicating the CoAP 527 request. 529 If the HTTP client times out and drops the HTTP session to the Cross- 530 Protocol Proxy (closing the TCP connection) after the HTTP request 531 was made, a Cross-Protocol Proxy SHOULD wait for the associated CoAP 532 response and cache it if possible. Further requests to the Cross- 533 Protocol Proxy for the same resource can use the result present in 534 cache, or, if a response has still to come, the HTTP requests will 535 wait on the open CoAP session. 537 According to [I-D.ietf-core-coap], a proxy MUST limit the number of 538 outstanding interactions to a given CoAP server to NSTART. To limit 539 the amount of aggregate traffic to a constrained network, the Cross- 540 Protocol Proxy SHOULD also pose a limit to the number of concurrent 541 CoAP requests pending on the same constrained network; further 542 incoming requests MAY either be queued or dropped (returning 503 543 Service Unavailable). This limit and the proxy queueing/dropping 544 behavior SHOULD be configurable. In order to efficiently apply this 545 congestion control, the Cross-Protocol Proxy SHOULD be SS placed. 547 Resources experiencing a high access rate coupled with high 548 volatility MAY be observed [I-D.ietf-core-observe] by the Cross- 549 Protocol Proxy to keep their cached representation fresh while 550 minimizing the number CoAP messages. See Section 6.5. 552 6.5. Cache Refresh via Observe 554 There are cases where using the CoAP observe protocol 555 [I-D.ietf-core-observe] to handle proxy cache refresh is preferable 556 to the validation mechanism based on ETag as defined in 557 [I-D.ietf-core-coap]. Such scenarios include, but are not limited 558 to, sleepy nodes -- with possibly high variance in requests' 559 distribution -- which would greatly benefit from a server driven 560 cache update mechanism. Ideal candidates would also be crowded or 561 very low throughput networks, where reduction of the total number of 562 exchanged messages is an important requirement. 564 This subsection aims at providing a practical evaluation method to 565 decide whether the refresh of a cached resource R is more efficiently 566 handled via ETag validation or by establishing an observation on R. 568 Let T_R be the mean time between two client requests to resource R, 569 let F_R be the freshness lifetime of R representation, and let M_R be 570 the total number of messages exchanged towards resource R. If we 571 assume that the initial cost for establishing the observation is 572 negligible, an observation on R reduces M_R iff T_R < 2*F_R with 573 respect to using ETag validation, that is iff the mean arrival time 574 of requests for resource R is greater than half the refresh rate of 575 R. 577 When using observations M_R is always upper bounded by 2*F_R: in the 578 constrained network no more than 2*F_R messages will be generated 579 towards resource R. 581 6.6. Use of CoAP Blockwise Transfer 583 A Cross-Protocol Proxy SHOULD support CoAP blockwise transfers 584 [I-D.ietf-core-block] to allow transport of large CoAP payloads while 585 avoiding excessive link-layer fragmentation in LLNs, and to cope with 586 small datagram buffers in CoAP end-points as described in 587 [I-D.ietf-core-coap] Section 4.6. 589 A Cross-Protocol Proxy SHOULD attempt to retry a payload-carrying 590 CoAP PUT or POST request with blockwise transfer if the destination 591 CoAP server responded with 4.13 (Request Entity Too Large) to the 592 original request. A Cross-Protocol Proxy SHOULD attempt to use 593 blockwise transfer when sending a CoAP PUT or POST request message 594 that is larger than a value BLOCKWISE_THRESHOLD. The value of 595 BLOCKWISE_THRESHOLD MAY be implementation-specific, for example 596 calculated based on a known or typical UDP datagram buffer size for 597 CoAP end-points, or set to N times the size of a link-layer frame 598 where e.g. N=5, or preset to a known IP MTU value, or set to a known 599 Path MTU value. The value BLOCKWISE_THRESHOLD or parameters from 600 which it is calculated SHOULD be configurable in a proxy 601 implementation. 603 The Cross-Protocol Proxy SHOULD detect CoAP end-points not supporting 604 blockwise transfers by checking for a 4.02 (Bad Option) response 605 returned by an end-point in response to a CoAP request with a Block* 606 Option. This allows the Cross-Protocol Proxy to be more efficient, 607 not attempting repeated blockwise transfers to CoAP servers that do 608 not support it. However if a request payload is too large to be sent 609 as a single CoAP request and blockwise transfer would be unavoidable, 610 the proxy still SHOULD attempt blockwise transfer on such an end- 611 point before returning 413 (Request Entity Too Large) to the HTTP 612 client. 614 For improved latency a cross proxy MAY initiate a blockwise CoAP 615 request triggered by an incoming HTTP request even when the HTTP 616 request message has not yet been fully received, but enough data has 617 been received to send one or more data blocks to a CoAP server 618 already. This is particularly useful on slow client-to-proxy 619 connections. 621 6.7. Security Translation 623 A HC proxy SHOULD implement explicit rules for security context 624 translations. A translation may involve e.g. applying a rule that 625 any "https" request is translated to a "coaps" request, or e.g. 626 applying a rule that a "https" request is translated to an unsecured 627 "coap" request. Another rule could specify the security policy and 628 parameters used for DTLS connections. Such rules will largely depend 629 on the application and network context in which a proxy is applied. 630 To enable widest possible use of a proxy implementation, these rules 631 SHOULD be configurable in a HC proxy. 633 If a policy for access to 'coaps' URIs is configurable in a HC proxy, 634 it is RECOMMENDED that the policy is by default configured to 635 disallow access to any 'coaps' URI by a HTTP client using an 636 unsecured (non-TLS) connection. Naturally, a user MAY reconfigure 637 the policy to allow such access in specific cases. 639 6.8. Other guidelines 641 For long delays of a CoAP server, the HTTP client or any other proxy 642 in between MAY timeout. Further discussion of timeouts in HTTP is 643 available in Section 6.2.4 of [I-D.ietf-httpbis-p1-messaging]. 645 A cross proxy MUST define an internal timeout for each pending CoAP 646 request, because the CoAP server may silently die before completing 647 the request. The timeout value SHOULD be approximately less than or 648 equal to MAX_RTT defined in [I-D.ietf-core-coap]. 650 When the DNS protocol is not used between CoAP nodes in a constrained 651 network, defining valid FQDN (i.e., DNS entries) for constrained CoAP 652 servers, where possible, MAY help HTTP clients to access the 653 resources offered by these servers via a HC proxy. 655 HTTP connection pipelining (section 6.2.2.1 of 656 [I-D.ietf-httpbis-p1-messaging]) MAY be supported by the proxy and is 657 transparent to the CoAP network: the HC cross proxy will sequentially 658 serve the pipelined requests by issuing different CoAP requests. 660 7. IANA Considerations 662 This memo includes no request to IANA. 664 8. Security Considerations 666 The security concerns raised in Section 15.7 of [RFC2616] also apply 667 to the cross proxy scenario. In fact, the cross proxy is a trusted 668 (not rarely a transparently trusted) component in the network path. 670 The trustworthiness assumption on the cross proxy cannot be dropped. 671 Even if we had a blind, bi-directional, end-to-end, tunneling 672 facility like the one provided by the CONNECT method in HTTP, and 673 also assuming the existence of a DTLS-TLS transparent mapping, the 674 two tunneled ends should be speaking the same application protocol, 675 which is not the case. Basically, the protocol translation function 676 is a core duty of the cross proxy that can't be removed, and makes it 677 a necessarily trusted, impossible to bypass, component in the 678 communication path. 680 A reverse proxy deployed at the boundary of a constrained network is 681 an easy single point of failure for reducing availability. As such, 682 a special care should be taken in designing, developing and operating 683 it, keeping in mind that, in most cases, it could have fewer 684 limitations than the constrained devices it is serving. 686 The following sub paragraphs categorize and argue about a set of 687 specific security issues related to the translation, caching and 688 forwarding functionality exposed by a cross proxy module. 690 8.1. Traffic overflow 692 Due to the typically constrained nature of CoAP nodes, particular 693 attention SHOULD be posed in the implementation of traffic reduction 694 mechanisms (see Section 6.4), because inefficient implementations can 695 be targeted by unconstrained Internet attackers. Bandwidth or 696 complexity involved in such attacks is very low. 698 An amplification attack to the constrained network may be triggered 699 by a multicast request generated by a single HTTP request mapped to a 700 CoAP multicast resource, as considered in Section TBD of 701 [I-D.ietf-core-coap]. 703 The impact of this amplification technique is higher than an 704 amplification attack carried out by a malicious constrained device 705 (e.g. ICMPv6 flooding, like Packet Too Big, or Parameter Problem on a 706 multicast destination [RFC4732]), since it does not require direct 707 access to the constrained network. 709 The feasibility of this attack, disruptive in terms of CoAP server 710 availability, can be limited by access controlling the exposed HTTP 711 multicast resource, so that only known/authorized users access such 712 URIs. 714 8.2. Handling Secured Exchanges 716 It is possible that the request from the client to the cross proxy is 717 sent over a secured connection. However, there may or may not exist 718 a secure connection mapping to the other protocol. For example, a 719 secure distribution method for multicast traffic is complex and MAY 720 not be implemented (see [I-D.ietf-core-groupcomm]). 722 By default, a cross proxy SHOULD reject any secured client request if 723 there is no configured security policy mapping. This recommendation 724 MAY be relaxed in case the destination network is believed to be 725 secured by other, complementary, means. E.g.: assumed that CoAP 726 nodes are isolated behind a firewall (e.g. as the SS cross proxy 727 deployment shown in Figure 1), the cross proxy may be configured to 728 translate the incoming HTTPS request using plain CoAP (i.e. NoSec 729 mode.) 731 The HC URI mapping MUST NOT map to HTTP (see Section 5) a CoAP 732 resource intended to be accessed only using HTTPS. 734 A secured connection that is terminated at the cross proxy, i.e. the 735 proxy decrypts secured data locally, raises an ambiguity about the 736 cacheability of the requested resource. The cross proxy SHOULD NOT 737 cache any secured content to avoid any leak of secured information. 738 However in some specific scenario, a security/efficiency trade-off 739 could motivate caching secured information; in that case the caching 740 behavior MAY be tuned to some extent on a per-resource basis. 742 9. Acknowledgements 744 An initial version of the table found in Section 6.2 has been 745 provided in revision -05 of [I-D.ietf-core-coap]. Special thanks to 746 Peter van der Stok for countless comments and discussions on this 747 document, that contributed to its current structure and text. 749 Thanks to Carsten Bormann, Zach Shelby, Michele Rossi, Nicola Bui, 750 Michele Zorzi, Klaus Hartke, Cullen Jennings, Kepeng Li, Brian Frank, 751 Peter Saint-Andre, Kerry Lynn, Linyi Tian, Dorothy Gellert, Francesco 752 Corazza for helpful comments and discussions that have shaped the 753 document. 755 The research leading to these results has received funding from the 756 European Community's Seventh Framework Programme [FP7/2007-2013] 757 under grant agreement n. [251557]. 759 10. References 761 10.1. Normative References 763 [I-D.ietf-core-block] 764 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 765 draft-ietf-core-block-12 (work in progress), June 2013. 767 [I-D.ietf-core-coap] 768 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 769 Application Protocol (CoAP)", draft-ietf-core-coap-18 770 (work in progress), June 2013. 772 [I-D.ietf-core-observe] 773 Hartke, K., "Observing Resources in CoAP", draft-ietf- 774 core-observe-10 (work in progress), September 2013. 776 [I-D.ietf-httpbis-p1-messaging] 777 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 778 (HTTP/1.1): Message Syntax and Routing", draft-ietf- 779 httpbis-p1-messaging-24 (work in progress), September 780 2013. 782 [I-D.ietf-httpbis-p2-semantics] 783 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 784 (HTTP/1.1): Semantics and Content", draft-ietf- 785 httpbis-p2-semantics-24 (work in progress), September 786 2013. 788 [I-D.ietf-httpbis-p7-auth] 789 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 790 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-24 791 (work in progress), September 2013. 793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 794 Requirement Levels", BCP 14, RFC 2119, March 1997. 796 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 797 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 798 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 800 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 801 Resource Identifier (URI): Generic Syntax", STD 66, RFC 802 3986, January 2005. 804 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 805 and D. Orchard, "URI Template", RFC 6570, March 2012. 807 10.2. Informative References 809 [I-D.ietf-core-groupcomm] 810 Rahman, A. and E. Dijk, "Group Communication for CoAP", 811 draft-ietf-core-groupcomm-16 (work in progress), October 812 2013. 814 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 815 Replication and Caching Taxonomy", RFC 3040, January 2001. 817 [RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of- 818 Service Considerations", RFC 4732, December 2006. 820 Appendix A. Change Log 822 Changes from ietf-01 to ietf-02: 824 o Selection of single default URI mapping proposal as proposed to WG 825 mailing list 2013-10-09. 827 Changes from ietf-00 to ietf-01: 829 o Added URI mapping proposals to Section 4 as per the Email 830 proposals to WG mailing list from Esko. 832 Authors' Addresses 834 Angelo P. Castellani 835 University of Padova 836 Via Gradenigo 6/B 837 Padova 35131 838 Italy 840 Email: angelo@castellani.net 841 Salvatore Loreto 842 Ericsson 843 Hirsalantie 11 844 Jorvas 02420 845 Finland 847 Email: salvatore.loreto@ericsson.com 849 Akbar Rahman 850 InterDigital Communications, LLC 851 1000 Sherbrooke Street West 852 Montreal H3A 3G4 853 Canada 855 Phone: +1 514 585 0761 856 Email: Akbar.Rahman@InterDigital.com 858 Thomas Fossati 859 KoanLogic 861 Email: tho@koanlogic.com 863 Esko Dijk 864 Philips Research 865 High Tech Campus 34 866 Eindhoven 5656 AE 867 The Netherlands 869 Email: esko.dijk@philips.com