idnits 2.17.1 draft-castellani-core-http-mapping-07.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 9 instances of too long lines in the document, the longest one being 1 character 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 (February 25, 2013) is 4070 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '251557' on line 686 == Unused Reference: 'I-D.bormann-core-simple-server-discovery' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'I-D.shelby-core-resource-directory' is defined on line 746, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-core-block-10 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-13 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-05 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-07 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-22 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-04 Summary: 2 errors (**), 0 flaws (~~), 11 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: August 29, 2013 Ericsson 6 A. Rahman 7 InterDigital Communications, LLC 8 T. Fossati 9 KoanLogic 10 E. Dijk 11 Philips Research 12 February 25, 2013 14 Best Practices for HTTP-CoAP Mapping Implementation 15 draft-castellani-core-http-mapping-07 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, discusses possible 22 approaches for URI mapping, and provides a set of guidelines and 23 considerations 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 August 29, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Cross-Protocol Usage of URIs . . . . . . . . . . . . . . . . . 4 62 4. HTTP to CoAP URI Mapping . . . . . . . . . . . . . . . . . . . 5 63 4.1. Embedded Mapping . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. Homogeneous Mapping . . . . . . . . . . . . . . . . . . . 5 65 4.3. Scheme Security Mapping . . . . . . . . . . . . . . . . . 6 66 5. HTTP-CoAP Reverse Proxy . . . . . . . . . . . . . . . . . . . 6 67 5.1. Proxy Placement . . . . . . . . . . . . . . . . . . . . . 7 68 5.2. Response Code Translations . . . . . . . . . . . . . . . . 8 69 5.3. Media Type Translations . . . . . . . . . . . . . . . . . 10 70 5.4. Caching and Congestion Control . . . . . . . . . . . . . . 11 71 5.5. Cache Refresh via Observe . . . . . . . . . . . . . . . . 11 72 5.6. Use of CoAP Blockwise Transfer . . . . . . . . . . . . . . 12 73 5.7. Security Translation . . . . . . . . . . . . . . . . . . . 13 74 5.8. Other guidelines . . . . . . . . . . . . . . . . . . . . . 13 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 7.1. Traffic overflow . . . . . . . . . . . . . . . . . . . . . 14 78 7.2. Handling Secured Exchanges . . . . . . . . . . . . . . . . 15 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 CoAP [I-D.ietf-core-coap] has been designed with the twofold aim to 88 be an application protocol specialized for constrained environments 89 and to be easily used in REST architectures such as the Web. The 90 latter goal has led to define CoAP to easily interoperate with HTTP 91 [RFC2616] through an intermediary proxy which performs cross-protocol 92 conversion. 94 Section 10 of [I-D.ietf-core-coap] describes the fundamentals of the 95 CoAP-HTTP (and vice-versa) cross-protocol mapping process. However, 96 implementing such a cross-protocol proxy can be complex, and many 97 details regarding its internal procedures and design choices require 98 further elaboration. Therefore a first goal of this document is to 99 provide more detailed information to proxy designers and 100 implementers, to help implement proxies that correctly inter-work 101 with other CoAP and HTTP client/server implementations that adhere to 102 the HTTP and CoAP specifications. 104 The second goal of this informational document is to define a 105 consistent set of guidelines that a HTTP-to-CoAP proxy implementation 106 MAY adhere to. The main reason of adhering to such guidelines is to 107 reduce variation between proxy implementations, thereby increasing 108 interoperability. (As an example use case, a proxy conforming to 109 these guidelines made by vendor A can be easily replaced by a proxy 110 from vendor B that also conforms to the guidelines.) 112 This draft is organized as follows: 114 o Section 2 describes terminology to identify proxy types, mapping 115 approaches and proxy deployments; 117 o Section 3 discusses how URIs refer to resources independent of 118 access protocols; 120 o Section 5 analyzes the mapping that allows HTTP clients to contact 121 CoAP servers; 123 o Section 7 discusses possible security impact related to HTTP/CoAP 124 cross-protocol mapping. 126 2. Terminology 128 This document assumes readers are familiar with the terms Reverse 129 Proxy as defined in [I-D.ietf-httpbis-p1-messaging] and Interception 130 Proxy as defined in [RFC3040]. In addition, the following terms are 131 defined: 133 Cross-Protocol Proxy (or Cross Proxy): is a proxy performing a cross- 134 protocol mapping, in the context of this document a HTTP-CoAP (HC) 135 mapping. A Cross-Protocol Proxy can behave as a Forward Proxy, 136 Reverse Proxy or Interception Proxy. Note: In this document we focus 137 on the Reverse Proxy mode of the Cross-Protocol Proxy. 139 Forward Proxy: a message forwarding agent that is selected by the 140 client, usually via local configuration rules, to receive requests 141 for some type(s) of absolute URI and to attempt to satisfy those 142 requests via translation to the protocol indicated by the absolute 143 URI. The user decides (is willing to) use the proxy as the 144 forwarding/dereferencing agent for a predefined subset of the URI 145 space. 147 Reverse Proxy: a receiving agent that acts as a layer above some 148 other server(s) and translates the received requests to the 149 underlying server's protocol. It behaves as an origin (HTTP) server 150 on its connection towards the (HTTP) client and as a (CoAP) client on 151 its connection towards the (CoAP) origin server. The (HTTP) client 152 uses the "origin-form" [I-D.ietf-httpbis-p1-messaging] as a request- 153 target URI. 155 Reverse and Forward proxies are technically very similar, with main 156 differences being that the former appears to a client as an origin 157 server while the latter does not, and that clients may be unaware 158 they are communicating with a proxy. 160 Placement terms: a server-side (SS) proxy is placed in the same 161 network domain as the server; conversely a client-side (CS) proxy is 162 in the same network domain as the client. In any other case than SS 163 or CS, the proxy is said to be External (E). 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in 168 [RFC2119]. 170 3. Cross-Protocol Usage of URIs 172 A Uniform Resource Identifier (URI) provides a simple and extensible 173 method for identifying a resource. It enables uniform identification 174 of resources via a separately defined extensible set of naming 175 schemes [RFC3986]. 177 URIs are formed of at least three components: scheme, authority and 178 path. The scheme often corresponds to the protocol used to access 179 the resource. However, as noted in Section 1.2.2 of [RFC3986] the 180 scheme does not imply that a particular protocol is used to access 181 the resource. So, we can define the same resource to be accessible 182 by different protocols i.e. the resource can have cross-protocol URIs 183 referring to it. 185 HTTP clients typically only support 'http' and 'https' schemes. 186 Therefore, they cannot directly access CoAP servers (which support 187 'coap' and/or 'coaps'). In this situation, communication is enabled 188 by a Cross-Protocol Proxy, as shown in Figure 1, supporting URI 189 mapping features. Such features are discussed in the following 190 section. 192 4. HTTP to CoAP URI Mapping 194 Assume that a HTTP client wants to access a CoAP resource and 195 indicates a target resource of "http://node.something.net/foobar" to 196 a Forward cross proxy. A possible URI mapping done by the proxy 197 could result in "coap://node.coap.something.net/foo". 199 As shown in the above example, in a cross-protocol URI the scheme, 200 authority and path parts of the URI may all change. The process of 201 providing cross-protocol URIs may be complex, since a mechanism to 202 statically or dynamically (e.g., discovery) map the URI is needed. 204 Two simple static URI mapping solutions are proposed in the following 205 subsections. Note that other mapping approaches are possible as 206 well. 208 4.1. Embedded Mapping 210 In an embedded mapping approach, the HTTP URI has embedded inside it 211 the authority and path part of the CoAP URI. 213 Example: The CoAP resource "//node.coap.something.net/foo" can be 214 accessed by an HTTP client by inserting in the request 215 "http://hc-proxy.something.net/coap/node.coap.something.net/foo". 216 The Cross-Protocol Proxy then maps the URI to 217 "coap://node.coap.something.net/foo" 219 4.2. Homogeneous Mapping 221 In a homogeneous mapping approach, only the scheme portion of the URI 222 needs to be mapped. The rest of the URI (i.e. authority, path, etc.) 223 remains unchanged. 225 Example: The CoAP resource "coap://node.coap.something.net/foo" can 226 be accessed by an HTTP client by requesting 227 "http://node.coap.something.net/foo". The Cross-Protocol Proxy 228 receiving the request is responsible to map the URI to 229 "coap://node.coap.something.net/foo" 231 Background info: The assumption in this case is that the HTTP client 232 would be able to successfully resolve "node.coap.something.net" using 233 DNS infrastructure to return the IP address of the HC proxy. Most 234 likely this would be through a two step DNS lookup where the first 235 DNS lookup would resolve "something.net" using public DNS 236 infrastructure. Then the second DNS lookup on the subdomain "coap" 237 and the host "node" would typically be resolved by a DNS server 238 operated by the owner of domain "something.net". So this domain 239 owner can manage its own internal node names and subdomain allocation 240 which would correspond to the CoAP namespace 242 4.3. Scheme Security Mapping 244 In general, regardless of the URI mapping scheme used in the Cross- 245 Protocol Proxy, an "https" request SHOULD be translated to a "coaps" 246 request. The exception case being cases where security on the CoAP 247 side is not needed because the network is well enough protected 248 already by other means (e.g. strong link-layer security, or the CoAP 249 network runs inside a firewalled network, etc.). 251 5. HTTP-CoAP Reverse Proxy 253 A HTTP-CoAP Reverse Cross-Protocol Proxy is accessed by web clients 254 only supporting HTTP, and handles their requests by mapping these to 255 CoAP requests, which are forwarded to CoAP servers; and mapping back 256 the received CoAP responses to HTTP. This mechanism is transparent 257 to the client, which may assume that it is communicating with the 258 intended target HTTP server. In other words, the client accesses the 259 proxy as an origin server using the "origin-form" 260 [I-D.ietf-httpbis-p1-messaging] as a Request Target. 262 Normative requirements on the translation of HTTP requests to CoAP 263 and of the CoAP responses back to HTTP responses are defined in 264 Section 10.2 of [I-D.ietf-core-coap]. However, that section only 265 considers the case of a HTTP-CoAP Forward Cross-Protocol Proxy in 266 which a client explicitly indicates it targets a request to a CoAP 267 server, and does not cover all aspects of proxy implementation in 268 detail. The present section provides guidelines and more details for 269 the implementation of a Reverse Cross-Protocol Proxy, which MAY be 270 followed in addition to the normative requirements. 272 Translation of unicast HTTP requests into multicast CoAP requests is 273 currently out of scope since in a reverse proxy scenario a HTTP 274 client typically expects to receive a single response, not multiple. 275 However a Cross-Protocol Proxy MAY include custom application- 276 specific functions to generate a multicast CoAP request based on a 277 unicast HTTP request and aggregate multiple CoAP responses into a 278 single HTTP response. 280 Note that the guidelines in this section also apply to an HTTP-CoAP 281 Intercepting Cross-Protocol Proxy. 283 5.1. Proxy Placement 285 Typically, a Cross-Protocol Proxy is located at the edge of the 286 constrained network. See Figure 1. The arguments supporting server- 287 side (SS) placement are the following: 289 Caching: Efficient caching requires that all request traffic to a 290 CoAP server is handled by the same proxy which receives HTTP 291 requests from multiple source locations. This maximally reduces 292 the load on (constrained) CoAP servers. 294 Multicast: To support CoAPs use of local-multicast functionalities 295 available in a constrained network, the Cross-Protocol Proxy 296 requires a network interface directly attached to the constrained 297 network. 299 TCP/UDP: Translation between HTTP and CoAP requires also TCP/UDP 300 translation; TCP may be the preferred way for communicating with 301 the constrained network due to its reliability or due to 302 intermediate gateways configured to block UDP traffic. 304 Arguments against SS placement, in favor of client-side (CS), are: 306 Scalability: A solution where a single SS proxy has to manage 307 numerous open TCP/IP connections to a large number of HTTP clients 308 is not scalable. (Unless multiple SS proxies are employed with a 309 load-balancing mechanism, which adds complexity.) 310 +------+ 311 | | 312 | DNS | 313 | | 314 +------+ Constrained Network 315 -------------------- 316 / \ 317 / /-----\ /-----\ \ 318 / CoAP CoAP \ 319 / server server \ 320 || \-----/ \-----/ || 321 +------+ HTTP Request +----------+ || 322 |HTTP |------------------------>| HTTP/CoAP| Req /-----\ || 323 |Client| | Cross- |------->| CoAP || 324 | |<------------------------| Proxy |<-------|server || 325 +------+ HTTP Response +----------+ Resp \-----/ || 326 || || 327 || /-----\ || 328 || CoAP || 329 \ server / 330 \ \-----/ / 331 \ /-----\ / 332 \ CoAP / 333 \ server / 334 \ \-----/ / 335 ---------------- 337 Figure 1: Reverse Cross-Protocol Proxy Deployment Scenario 339 5.2. Response Code Translations 341 Table 1 defines all possible CoAP responses along with the HTTP 342 response to which each CoAP response SHOULD be translated. This 343 table complies with the Section 10.2 requirements of 344 [I-D.ietf-core-coap] and is intended to cover all possible cases. 345 Multiple appearances of a HTTP status code in the second column 346 indicates multiple equivalent HTTP responses are possible, depending 347 on the conditions cited in the Notes (third column). 349 +-----------------------------+-----------------------------+-------+ 350 | CoAP Response Code | HTTP Status Code | Notes | 351 +-----------------------------+-----------------------------+-------+ 352 | 2.01 Created | 201 Created | 1 | 353 | 2.02 Deleted | 200 OK | 2 | 354 | | 204 No Content | 2 | 355 | 2.03 Valid | 304 Not Modified | 3 | 356 | | 200 OK | 4 | 357 | 2.04 Changed | 200 OK | 2 | 358 | | 204 No Content | 2 | 359 | 2.05 Content | 200 OK | | 360 | 4.00 Bad Request | 400 Bad Request | | 361 | 4.01 Unauthorized | 400 Bad Request | 5 | 362 | 4.02 Bad Option | 400 Bad Request | 6 | 363 | 4.03 Forbidden | 403 Forbidden | | 364 | 4.04 Not Found | 404 Not Found | | 365 | 4.05 Method Not Allowed | 400 Bad Request | 7 | 366 | 4.06 Not Acceptable | 406 Not Acceptable | | 367 | 4.12 Precondition Failed | 412 Precondition Failed | | 368 | 4.13 Request Entity Too | 413 Request Repr. Too Large | | 369 | Large | | | 370 | 4.15 Unsupported Media Type | 415 Unsupported Media Type | | 371 | 5.00 Internal Server Error | 500 Internal Server Error | | 372 | 5.01 Not Implemented | 501 Not Implemented | | 373 | 5.02 Bad Gateway | 502 Bad Gateway | | 374 | 5.03 Service Unavailable | 503 Service Unavailable | 8 | 375 | 5.04 Gateway Timeout | 504 Gateway Timeout | | 376 | 5.05 Proxying Not Supported | 502 Bad Gateway | 9 | 377 +-----------------------------+-----------------------------+-------+ 379 Table 1: HTTP-CoAP Response Mapping 381 Notes: 383 1. A CoAP server may return an arbitrary format payload along with 384 this response. This payload SHOULD be returned as entity in the 385 HTTP 201 response. Section 7.3.2 of 386 [I-D.ietf-httpbis-p2-semantics] does not put any requirement on 387 the format of the payload. (In the past, [RFC2616] did.) 389 2. The HTTP code is 200 or 204 respectively for the case that a CoAP 390 server returns a payload or not. [I-D.ietf-httpbis-p2-semantics] 391 Section 5.3 requires code 200 in case a representation of the 392 action result is returned for DELETE, POST and PUT and code 204 393 if not. Hence, a proxy SHOULD transfer any CoAP payload 394 contained in a 2.02 response to the HTTP client in a 200 OK 395 response. 397 3. A CoAP 2.03 (Valid) response only (1) confirms that the request 398 ETag is valid and (2) provides a new Max-Age value. HTTP 304 399 (Not Modified) also updates some header fields of a stored 400 response. A non-caching proxy may not have enough information to 401 fill in the required values in the HTTP 304 (Not Modified) 402 response, so it may not be advisable for a non-caching proxy to 403 provoke the 2.03 (Valid) response by forwarding an ETag. A 404 caching proxy will fill the information out of the cache. 406 4. A 200 response to a CoAP 2.03 occurs only when the proxy is 407 caching and translated a HTTP request (without validation 408 request) to a CoAP request that includes validation, for 409 efficiency. The proxy receiving 2.03 updates the freshness of 410 the cached representation and returns the entire representation 411 to the HTTP client. 413 5. The HTTP code 401 Unauthorized MUST NOT be used, as long as in 414 CoAP there is no equivalent defined of the required WWW- 415 Authenticate header (Section 3.1 of [I-D.ietf-httpbis-p7-auth]). 417 6. In some cases a proxy receiving 4.02 may retry the request with 418 less CoAP Options in the hope that the server will understand the 419 newly formulated request. For example, if the proxy tried using 420 a Block Option which was not recognized by the CoAP server it may 421 retry without that Block Option. 423 7. The HTTP code "405 Method Not Allowed" MUST NOT be used since 424 CoAP does not provide enough information to determine a value for 425 the required "Allow" response-header field. 427 8. The value of the HTTP "Retry-After" response-header field is 428 taken from the value of the CoAP Max-Age Option, if present. 430 9. This CoAP response can only happen if the proxy itself is 431 configured to use a CoAP Forward Proxy to execute some, or all, 432 of its CoAP requests. 434 5.3. Media Type Translations 436 A Cross-Protocol Proxy translates a media type string, carried in a 437 HTTP Content-Type header in a request, to a CoAP Content-Format 438 Option with the equivalent numeric value. The media types supported 439 by CoAP are defined in the CoAP Content-Format Registry. Any HTTP 440 request with a Content-Type for which the proxy does not know an 441 equivalent CoAP Content-Format number, MUST lead to HTTP response 415 442 (Unsupported Media Type). 444 Also, a CoAP Content-Format value in a response is translated back to 445 the equivalent HTTP Content-Type. If a proxy receives a CoAP 446 Content-Format value that it does not recognize (e.g. because the 447 value is IANA-registered after the proxy software was deployed), and 448 is unable to look up the equivalent HTTP Content-Type on the fly, the 449 proxy SHOULD return an HTTP entity (payload) without Content-Type 450 header (complying to Section 3.1.1.5 of 451 [I-D.ietf-httpbis-p2-semantics]). 453 5.4. Caching and Congestion Control 455 A Cross-Protocol Proxy SHOULD limit the number of requests to CoAP 456 servers by responding, where applicable, with a cached representation 457 of the resource. 459 Duplicate idempotent pending requests by a Cross-Protocol Proxy to 460 the same CoAP resource SHOULD in general be avoided, by duplexing the 461 response to the requesting HTTP clients without duplicating the CoAP 462 request. 464 If the HTTP client times out and drops the HTTP session to the Cross- 465 Protocol Proxy (closing the TCP connection) after the HTTP request 466 was made, a Cross-Protocol Proxy SHOULD wait for the associated CoAP 467 response and cache it if possible. Further requests to the Cross- 468 Protocol Proxy for the same resource can use the result present in 469 cache, or, if a response has still to come, the HTTP requests will 470 wait on the open CoAP session. 472 According to [I-D.ietf-core-coap], a proxy MUST limit the number of 473 outstanding interactions to a given CoAP server to NSTART. To limit 474 the amount of aggregate traffic to a constrained network, the Cross- 475 Protocol Proxy SHOULD also pose a limit to the number of concurrent 476 CoAP requests pending on the same constrained network; further 477 incoming requests MAY either be queued or dropped (returning 503 478 Service Unavailable). This limit and the proxy queueing/dropping 479 behavior SHOULD be configurable. In order to efficiently apply this 480 congestion control, the Cross-Protocol Proxy SHOULD be SS placed. 482 Resources experiencing a high access rate coupled with high 483 volatility MAY be observed [I-D.ietf-core-observe] by the Cross- 484 Protocol Proxy to keep their cached representation fresh while 485 minimizing the number CoAP messages. See Section 5.5. 487 5.5. Cache Refresh via Observe 489 There are cases where using the CoAP observe protocol 490 [I-D.ietf-core-observe] to handle proxy cache refresh is preferable 491 to the validation mechanism based on ETag as defined in 492 [I-D.ietf-core-coap]. Such scenarios include, but are not limited 493 to, sleepy nodes -- with possibly high variance in requests' 494 distribution -- which would greatly benefit from a server driven 495 cache update mechanism. Ideal candidates would also be crowded or 496 very low throughput networks, where reduction of the total number of 497 exchanged messages is an important requirement. 499 This subsection aims at providing a practical evaluation method to 500 decide whether the refresh of a cached resource R is more efficiently 501 handled via ETag validation or by establishing an observation on R. 503 Let T_R be the mean time between two client requests to resource R, 504 let F_R be the freshness lifetime of R representation, and let M_R be 505 the total number of messages exchanged towards resource R. If we 506 assume that the initial cost for establishing the observation is 507 negligible, an observation on R reduces M_R iff T_R < 2*F_R with 508 respect to using ETag validation, that is iff the mean arrival time 509 of requests for resource R is greater than half the refresh rate of 510 R. 512 When using observations M_R is always upper bounded by 2*F_R: in the 513 constrained network no more than 2*F_R messages will be generated 514 towards resource R. 516 5.6. Use of CoAP Blockwise Transfer 518 A Cross-Protocol Proxy SHOULD support CoAP blockwise transfers 519 [I-D.ietf-core-block] to allow transport of large CoAP payloads while 520 avoiding excessive link-layer fragmentation in LLNs, and to cope with 521 small datagram buffers in CoAP end-points as described in 522 [I-D.ietf-core-coap] Section 4.6. 524 A Cross-Protocol Proxy SHOULD attempt to retry a payload-carrying 525 CoAP PUT or POST request with blockwise transfer if the destination 526 CoAP server responded with 4.13 (Request Entity Too Large) to the 527 original request. A Cross-Protocol Proxy SHOULD attempt to use 528 blockwise transfer when sending a CoAP PUT or POST request message 529 that is larger than a value BLOCKWISE_THRESHOLD. The value of 530 BLOCKWISE_THRESHOLD MAY be implementation-specific, for example 531 calculated based on a known or typical UDP datagram buffer size for 532 CoAP end-points, or set to N times the size of a link-layer frame 533 where e.g. N=5, or preset to a known IP MTU value, or set to a known 534 Path MTU value. The value BLOCKWISE_THRESHOLD or parameters from 535 which it is calculated SHOULD be configurable in a proxy 536 implementation. 538 The Cross-Protocol Proxy SHOULD detect CoAP end-points not supporting 539 blockwise transfers by checking for a 4.02 (Bad Option) response 540 returned by an end-point in response to a CoAP request with a Block* 541 Option. This allows the Cross-Protocol Proxy to be more efficient, 542 not attempting repeated blockwise transfers to CoAP servers that do 543 not support it. However if a request payload is too large to be sent 544 as a single CoAP request and blockwise transfer would be unavoidable, 545 the proxy still SHOULD attempt blockwise transfer on such an end- 546 point before returning 413 (Request Entity Too Large) to the HTTP 547 client. 549 For improved latency a cross proxy MAY initiate a blockwise CoAP 550 request triggered by an incoming HTTP request even when the HTTP 551 request message has not yet been fully received, but enough data has 552 been received to send one or more data blocks to a CoAP server 553 already. This is particularly useful on slow client-to-proxy 554 connections. 556 5.7. Security Translation 558 A HC proxy SHOULD implement explicit rules for security context 559 translations. A translation may involve e.g. applying a rule that 560 any "https" request is translated to a "coaps" request, or e.g. 561 applying a rule that a "https" request is translated to an unsecured 562 "coap" request. Another rule could specify the security policy and 563 parameters used for DTLS connections. Such rules will largely depend 564 on the application and network context in which a proxy is applied. 565 To enable widest possible use of a proxy implementation, these rules 566 SHOULD be configurable in a HC proxy. 568 5.8. Other guidelines 570 For long delays of a CoAP server, the HTTP client or any other proxy 571 in between MAY timeout. Further discussion of timeouts in HTTP is 572 available in Section 6.2.4 of [I-D.ietf-httpbis-p1-messaging]. 574 A cross proxy MUST define an internal timeout for each pending CoAP 575 request, because the CoAP server may silently die before completing 576 the request. The timeout value SHOULD be approximately less than or 577 equal to MAX_RTT defined in [I-D.ietf-core-coap]. 579 When the DNS protocol is not used between CoAP nodes in a constrained 580 network, defining valid FQDN (i.e., DNS entries) for constrained CoAP 581 servers, where possible, MAY help HTTP clients to access the 582 resources offered by these servers via a HC proxy. 584 HTTP connection pipelining (section 6.2.2.1 of 585 [I-D.ietf-httpbis-p1-messaging]) MAY be supported by the proxy and is 586 transparent to the CoAP network: the HC cross proxy will sequentially 587 serve the pipelined requests by issuing different CoAP requests. 589 6. IANA Considerations 591 This memo includes no request to IANA. 593 7. Security Considerations 595 The security concerns raised in Section 15.7 of [RFC2616] also apply 596 to the cross proxy scenario. In fact, the cross proxy is a trusted 597 (not rarely a transparently trusted) component in the network path. 599 The trustworthiness assumption on the cross proxy cannot be dropped. 600 Even if we had a blind, bi-directional, end-to-end, tunneling 601 facility like the one provided by the CONNECT method in HTTP, and 602 also assuming the existence of a DTLS-TLS transparent mapping, the 603 two tunneled ends should be speaking the same application protocol, 604 which is not the case. Basically, the protocol translation function 605 is a core duty of the cross proxy that can't be removed, and makes it 606 a necessarily trusted, impossible to bypass, component in the 607 communication path. 609 A reverse proxy deployed at the boundary of a constrained network is 610 an easy single point of failure for reducing availability. As such, 611 a special care should be taken in designing, developing and operating 612 it, keeping in mind that, in most cases, it could have fewer 613 limitations than the constrained devices it is serving. 615 The following sub paragraphs categorize and argue about a set of 616 specific security issues related to the translation, caching and 617 forwarding functionality exposed by a cross proxy module. 619 7.1. Traffic overflow 621 Due to the typically constrained nature of CoAP nodes, particular 622 attention SHOULD be posed in the implementation of traffic reduction 623 mechanisms (see Section 5.4), because inefficient implementations can 624 be targeted by unconstrained Internet attackers. Bandwidth or 625 complexity involved in such attacks is very low. 627 An amplification attack to the constrained network may be triggered 628 by a multicast request generated by a single HTTP request mapped to a 629 CoAP multicast resource, as considered in Section TBD of 630 [I-D.ietf-core-coap]. 632 The impact of this amplification technique is higher than an 633 amplification attack carried out by a malicious constrained device 634 (e.g. ICMPv6 flooding, like Packet Too Big, or Parameter Problem on 635 a multicast destination [RFC4732]), since it does not require direct 636 access to the constrained network. 638 The feasibility of this attack, disruptive in terms of CoAP server 639 availability, can be limited by access controlling the exposed HTTP 640 multicast resource, so that only known/authorized users access such 641 URIs. 643 7.2. Handling Secured Exchanges 645 It is possible that the request from the client to the cross proxy is 646 sent over a secured connection. However, there may or may not exist 647 a secure connection mapping to the other protocol. For example, a 648 secure distribution method for multicast traffic is complex and MAY 649 not be implemented (see [I-D.ietf-core-groupcomm]). 651 By default, a cross proxy SHOULD reject any secured client request if 652 there is no configured security policy mapping. This recommendation 653 MAY be relaxed in case the destination network is believed to be 654 secured by other, complementary, means. E.g.: assumed that CoAP 655 nodes are isolated behind a firewall (e.g. as the SS cross proxy 656 deployment shown in Figure 1), the cross proxy may be configured to 657 translate the incoming HTTPS request using plain CoAP (i.e. NoSec 658 mode.) 660 The HC URI mapping MUST NOT map to HTTP (see Section 4) a CoAP 661 resource intended to be accessed only using HTTPS. 663 A secured connection that is terminated at the cross proxy, i.e. the 664 proxy decrypts secured data locally, raises an ambiguity about the 665 cacheability of the requested resource. The cross proxy SHOULD NOT 666 cache any secured content to avoid any leak of secured information. 667 However in some specific scenario, a security/efficiency trade-off 668 could motivate caching secured information; in that case the caching 669 behavior MAY be tuned to some extent on a per-resource basis. 671 8. Acknowledgements 673 An initial version of the table found in Section 5.2 has been 674 provided in revision -05 of [I-D.ietf-core-coap]. Special thanks to 675 Peter van der Stok for countless comments and discussions on this 676 document, that contributed to its current structure and text. 678 Thanks to Carsten Bormann, Zach Shelby, Michele Rossi, Nicola Bui, 679 Michele Zorzi, Klaus Hartke, Cullen Jennings, Kepeng Li, Brian Frank, 680 Peter Saint-Andre, Kerry Lynn, Linyi Tian, Dorothy Gellert, Francesco 681 Corazza for helpful comments and discussions that have shaped the 682 document. 684 The research leading to these results has received funding from the 685 European Community's Seventh Framework Programme [FP7/2007-2013] 686 under grant agreement n. [251557]. 688 9. References 690 9.1. Normative References 692 [I-D.ietf-core-block] 693 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 694 draft-ietf-core-block-10 (work in progress), October 2012. 696 [I-D.ietf-core-coap] 697 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 698 "Constrained Application Protocol (CoAP)", 699 draft-ietf-core-coap-13 (work in progress), December 2012. 701 [I-D.ietf-core-groupcomm] 702 Rahman, A. and E. Dijk, "Group Communication for CoAP", 703 draft-ietf-core-groupcomm-05 (work in progress), 704 February 2013. 706 [I-D.ietf-core-observe] 707 Hartke, K., "Observing Resources in CoAP", 708 draft-ietf-core-observe-07 (work in progress), 709 October 2012. 711 [I-D.ietf-httpbis-p1-messaging] 712 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 713 (HTTP/1.1): Message Syntax and Routing", 714 draft-ietf-httpbis-p1-messaging-22 (work in progress), 715 February 2013. 717 [I-D.ietf-httpbis-p2-semantics] 718 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 719 (HTTP/1.1): Semantics and Content", 720 draft-ietf-httpbis-p2-semantics-22 (work in progress), 721 February 2013. 723 [I-D.ietf-httpbis-p7-auth] 724 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 725 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-22 726 (work in progress), February 2013. 728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 729 Requirement Levels", BCP 14, RFC 2119, March 1997. 731 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 732 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 733 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 735 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 736 Resource Identifier (URI): Generic Syntax", STD 66, 737 RFC 3986, January 2005. 739 9.2. Informative References 741 [I-D.bormann-core-simple-server-discovery] 742 Bormann, C., "CoRE Simple Server Discovery", 743 draft-bormann-core-simple-server-discovery-01 (work in 744 progress), March 2012. 746 [I-D.shelby-core-resource-directory] 747 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 748 Directory", draft-shelby-core-resource-directory-04 (work 749 in progress), July 2012. 751 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 752 Replication and Caching Taxonomy", RFC 3040, January 2001. 754 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 755 Service Considerations", RFC 4732, December 2006. 757 Authors' Addresses 759 Angelo P. Castellani 760 University of Padova 761 Via Gradenigo 6/B 762 Padova 35131 763 Italy 765 Email: angelo@castellani.net 767 Salvatore Loreto 768 Ericsson 769 Hirsalantie 11 770 Jorvas 02420 771 Finland 773 Email: salvatore.loreto@ericsson.com 774 Akbar Rahman 775 InterDigital Communications, LLC 776 1000 Sherbrooke Street West 777 Montreal H3A 3G4 778 Canada 780 Phone: +1 514 585 0761 781 Email: Akbar.Rahman@InterDigital.com 783 Thomas Fossati 784 KoanLogic 785 Via di Sabbiuno 11/5 786 Bologna 40136 787 Italy 789 Phone: +39 051 644 82 68 790 Email: tho@koanlogic.com 792 Esko Dijk 793 Philips Research 794 High Tech Campus 34 795 Eindhoven 5656 AE 796 The Netherlands 798 Email: esko.dijk@philips.com