idnits 2.17.1 draft-ietf-core-http-mapping-05.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 10 instances of too long lines in the document, the longest one being 3 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 23, 2014) is 3471 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'C-T' is mentioned on line 879, but not defined == Missing Reference: 'C-E' is mentioned on line 865, but not defined -- Looks like a reference, but probably isn't: '251557' on line 1203 == Unused Reference: 'RFC6570' is defined on line 1224, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-core-block-15 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-14 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 5 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 26, 2015 Ericsson 6 A. Rahman 7 InterDigital Communications, LLC 8 T. Fossati 9 Alcatel-Lucent 10 E. Dijk 11 Philips Research 12 October 23, 2014 14 Guidelines for HTTP-CoAP Mapping Implementations 15 draft-ietf-core-http-mapping-05 17 Abstract 19 This draft provides reference information for HTTP-CoAP protocol 20 translation proxy implementation, focusing on the reverse proxy case. 21 It details deployment options, defines a template for URI mapping, 22 and provides a set of guidelines and considerations related to 23 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 26, 2015. 42 Copyright Notice 44 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Cross-Protocol Usage of URIs . . . . . . . . . . . . . . . . 4 62 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. URI Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. URI Terminology . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Default Mapping . . . . . . . . . . . . . . . . . . . . . 6 66 5.2.1. Optional scheme . . . . . . . . . . . . . . . . . . . 7 67 5.2.2. Encoding Caveats . . . . . . . . . . . . . . . . . . 7 68 5.3. URI Mapping Template . . . . . . . . . . . . . . . . . . 7 69 5.3.1. Simple Form . . . . . . . . . . . . . . . . . . . . . 8 70 5.3.2. Enhanced Form . . . . . . . . . . . . . . . . . . . . 9 71 5.4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.4.1. Examples . . . . . . . . . . . . . . . . . . . . . . 11 73 6. HTTP-CoAP Reverse Proxy . . . . . . . . . . . . . . . . . . . 12 74 6.1. Proxy Placement . . . . . . . . . . . . . . . . . . . . . 13 75 6.2. Response Code Translations . . . . . . . . . . . . . . . 14 76 6.3. Media Type mapping . . . . . . . . . . . . . . . . . . . 16 77 6.3.1. Loose Media Type Mapping . . . . . . . . . . . . . . 18 78 6.3.2. Internet Media Type to Content Format Mapping 79 Algorithm . . . . . . . . . . . . . . . . . . . . . . 18 80 6.3.3. Content Transcoding . . . . . . . . . . . . . . . . . 19 81 6.4. Caching and Congestion Control . . . . . . . . . . . . . 21 82 6.5. Cache Refresh via Observe . . . . . . . . . . . . . . . . 21 83 6.6. Use of CoAP Blockwise Transfer . . . . . . . . . . . . . 22 84 6.7. Security Translation . . . . . . . . . . . . . . . . . . 23 85 6.8. Other guidelines . . . . . . . . . . . . . . . . . . . . 23 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 88 8.1. Traffic overflow . . . . . . . . . . . . . . . . . . . . 24 89 8.2. Handling Secured Exchanges . . . . . . . . . . . . . . . 25 90 8.3. URI Mapping . . . . . . . . . . . . . . . . . . . . . . . 25 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 94 10.2. Informative References . . . . . . . . . . . . . . . . . 27 95 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 98 1. Introduction 100 CoAP [RFC7252] has been designed with the twofold aim to be an 101 application protocol specialized for constrained environments and to 102 be easily used in REST architectures such as the Web. The latter 103 goal has led to define CoAP to easily interoperate with HTTP 104 [RFC7230] through an intermediary proxy which performs cross-protocol 105 conversion. 107 Section 10 of [RFC7252] describes the fundamentals of the CoAP-to- 108 HTTP and the HTTP-to-CoAP cross-protocol mapping process. However, 109 implementing such a cross-protocol proxy can be complex, and many 110 details regarding its internal procedures and design choices require 111 further elaboration. Therefore a first goal of this document is to 112 provide more detailed information to proxy designers and 113 implementers, to help implement proxies that correctly inter-work 114 with other CoAP and HTTP client/server implementations that adhere to 115 the HTTP and CoAP specifications. 117 The second goal of this informational document is to define a 118 consistent set of guidelines that a HTTP-to-CoAP proxy implementation 119 MAY adhere to. The main reason of adhering to such guidelines is to 120 reduce variation between proxy implementations, thereby increasing 121 interoperability. (As an example use case, a proxy conforming to 122 these guidelines made by vendor A can be easily replaced by a proxy 123 from vendor B that also conforms to the guidelines.) 125 This draft is organized as follows: 127 o Section 2 describes terminology to identify proxy types, mapping 128 approaches and proxy deployments; 130 o Section 3 discusses how URIs refer to resources independent of 131 access protocols; 133 o Section 4 briefly lists use cases in which HTTP clients need to 134 contact CoAP servers; 136 o Section 5 introduces a default HTTP-to-CoAP URI mapping syntax; 138 o Section 6 describes the properties of the HTTP-to-CoAP reverse 139 proxy; 141 o Section 8 discusses possible security impact related to HTTP-CoAP 142 protocol mapping. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in 149 [RFC2119]. 151 This document assumes readers are familiar with the terms Reverse 152 Proxy as defined in [RFC7230] and Interception Proxy as defined in 153 [RFC3040]. In addition, the following terms are defined: 155 HC Proxy: is a proxy performing a cross-protocol mapping, in the 156 context of this document a HTTP-CoAP (HC) mapping. A Cross-Protocol 157 Proxy can behave as a Forward Proxy, Reverse Proxy or Interception 158 Proxy. Note: In this document we focus on the Reverse Proxy mode of 159 the Cross-Protocol Proxy. 161 Forward Proxy: a message forwarding agent that is selected by the 162 client, usually via local configuration rules, to receive requests 163 for some type(s) of absolute URI and to attempt to satisfy those 164 requests via translation to the protocol indicated by the absolute 165 URI. The user decides (is willing to) use the proxy as the 166 forwarding/dereferencing agent for a predefined subset of the URI 167 space. 169 Reverse Proxy: a receiving agent that acts as a layer above some 170 other server(s) and translates the received requests to the 171 underlying server's protocol. It behaves as an origin (HTTP) server 172 on its connection towards the (HTTP) client and as a (CoAP) client on 173 its connection towards the (CoAP) origin server. The (HTTP) client 174 uses the "origin-form" [RFC7230] as a request-target URI. 176 Reverse and Forward proxies are technically very similar, with main 177 differences being that the former appears to a client as an origin 178 server while the latter does not, and that clients may be unaware 179 they are communicating with a proxy. 181 Placement terms: a server-side (SS) proxy is placed in the same 182 network domain as the server; conversely a client-side (CS) proxy is 183 in the same network domain as the client. In any other case than SS 184 or CS, the proxy is said to be External (E). 186 3. Cross-Protocol Usage of URIs 188 A Uniform Resource Identifier (URI) provides a simple and extensible 189 method for identifying a resource. It enables uniform identification 190 of resources via a separately defined extensible set of naming 191 schemes [RFC3986]. 193 URIs are formed of at least three components: scheme, authority and 194 path. The scheme often corresponds to the protocol used to access 195 the resource. However, as noted in Section 1.2.2 of [RFC3986] the 196 scheme does not imply that a particular protocol is used to access 197 the resource. So, we can define the same resource to be accessible 198 by different protocols i.e., the resource can have cross-protocol 199 URIs referring to it. 201 HTTP clients only support 'http' and 'https' schemes and cannot 202 directly access CoAP servers (which support 'coap' and/or 'coaps'). 203 In this situation, communication is enabled by a HC Proxy, as shown 204 in Figure 1, supporting URI mapping features. Such features are 205 discussed in Section 5. 207 4. Use Cases 209 To illustrate in which situations HTTP to CoAP request mapping may be 210 used, three use cases are briefly described. 212 1. Smartphone and home sensor: A smartphone can access directly a 213 home sensor using an authenticated 'https' request, if its home 214 router contains a HTTP-CoAP proxy. For this use-case an HTML5 215 application on the smartphone can provide a friendly UI to the user. 217 2. Legacy building control application without CoAP: A building 218 control application that uses HTTP but not CoAP, can check the status 219 of sensors and/or actuators via a HTTP-CoAP proxy. 221 3. Making sensor data available to 3rd parties: For demonstration or 222 public interest purposes, a HTTP-CoAP proxy may be configured to 223 expose the contents of a sensor to the world via the web (HTTP and/or 224 HTTPS). The sensor can only handle secure 'coaps' requests, 225 therefore the proxy is configured to translate any request to a 226 'coaps' secured request. The proxy is furthermore configured to only 227 pass through GET requests. In this way even unattended HTTP clients, 228 such as web crawlers, may index sensor data as regular web pages. 230 5. URI Mapping 232 Though, in principle, a CoAP URI could be directly used by a HTTP 233 user agent to de-reference a CoAP resource through a HC Proxy, the 234 reality is that all major web browsers and command line tools do not 235 allow making HTTP requests using URIs with a scheme different from 236 "http" or "https". 238 Thus, there is a need for web applications to "pack" a CoAP URI into 239 a HTTP URI so that it can be (non-destructively) transported from the 240 user agent to the HC Proxy. The HC Proxy can then "unpack" the CoAP 241 URI and finally de-reference it via a CoAP request to the target 242 Server. 244 URI Mapping is the process through which the URI of a CoAP resource 245 is transformed in to an HTTP URI so that: 247 o the requesting HTTP user agent can handle it; 249 o the receiving HC Proxy can extract the intended CoAP URI 250 unambiguously. 252 To this end, the remainder of this section will identify: 254 o the default mechanism to map a CoAP URI into a HTTP URI; 256 o the URI template format to express a class of CoAP-HTTP URI 257 mapping functions; 259 o the discovery mechanism based on [RFC6690] through which clients 260 of a HC Proxy can dynamically discover information about the 261 supported URI Mapping Template(s), as well as the base URI where 262 the HC Proxy function is anchored. 264 5.1. URI Terminology 266 In the remainder of this section, the following terms will be used 267 with a distinctive meaning: 269 Target CoAP URI: 270 URI which refers to the (final) CoAP resource that has to be 271 de-referenced. It conforms to syntax defined in section 6 of 272 [RFC7252]. Specifically, it has a scheme of "coap" or 273 "coaps". 275 Hosting HTTP URI: 276 URI that conforms to syntax in section 2.7 of [RFC7230]. Its 277 authority component refers to an HC Proxy, whereas path (and 278 query) component(s) embed the information used by an HC Proxy 279 to extract the Target CoAP URI. 281 5.2. Default Mapping 283 The default is for the Target CoAP URI to be appended as-is to a base 284 URI provided by the HC Proxy to form the Hosting HTTP URI. 286 For example: given a base URI http://p.example.com/hc and a Target 287 CoAP URI coap://s.example.com/light, the resulting Hosting HTTP URI 288 would be http://p.example.com/hc/coap://s.example.com/light. 290 Provided a correct Target CoAP URI, the Hosting HTTP URI resulting 291 from the default mapping is always syntactically correct. 292 Furthermore, the Target CoAP URI can always be extracted in an 293 unambiguous way from the Hosting HTTP URI. Also worth noting that, 294 using the default mapping, a query component in the target CoAP 295 resource URI is naturally encoded into the query component of the 296 Hosting URI, e.g.: coap://s.example.com/light?dim=5 becomes 297 http://p.example.com/hc/coap://s.example.com/light?dim=5. 299 There is no default for the base URI. Therefore it is either known 300 in advance, e.g. as a configuration preset, or dynamically discovered 301 using the mechanism described in Section 5.4. 303 The default URI mapping function is RECOMMENDED to be implemented and 304 activated by default in a HC Proxy, unless there are valid reasons, 305 e.g. application specific, to use a different mapping function. 307 5.2.1. Optional scheme 309 When found in a Hosting HTTP URI, the scheme (i.e., "coap" or 310 "coaps"), the scheme component delimiter (":"), and the double slash 311 ("//") preceding the authority MAY be omitted. In such case, a local 312 default - not defined by this document - applies. 314 So, http://p.example.com/hc/s.coap.example.com/foo could either 315 represent the target coap://s.coap.example.com/foo or 316 coaps://s.coap.example.com/foo depending on application specific 317 presets. 319 5.2.2. Encoding Caveats 321 When the authority of the Target CoAP URI is given as an IPv6address, 322 then the surrounding square brackets MUST be percent-encoded in the 323 Hosting HTTP URI, in order to comply with the syntax defined in 324 Section 3.3. of [RFC3986] for a URI path segment. E.g.: 325 coap://[2001:db8::1]/light?on becomes 326 http://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on. 328 Everything else can be safely copied verbatim from the Target CoAP 329 URI to the Hosting HTTP URI. 331 5.3. URI Mapping Template 333 This section defines a format for the URI template used by a HC Proxy 334 to inform its clients about the expected syntax for the Hosting HTTP 335 URI. 337 When instantiated, an URI Mapping Template is always concatenated to 338 a base URI provided by the HC Proxy via discovery (see Section 5.4), 339 or by other means. 341 A simple form (Section 5.3.1) and an enhanced form (Section 5.3.2) 342 are provided to fit different users' requirements. 344 Both forms are expressed as level 2 URI template's to take care of 345 the expansion of values that are allowed to include reserved URI 346 characters. 348 5.3.1. Simple Form 350 The simple form MUST be used for mappings where the Target CoAP URI 351 is going to be copied verbatim at some fixed position into the 352 Hosting HTTP URI. 354 The following template variables MUST be used in mutual exclusion in 355 a template definition: 357 cu = coap-URI ; from [RFC7252], Section 6.1 358 su = coaps-URI ; from [RFC7252], Section 6.2 359 tu = cu / su 361 The same considerations done in Section 5.2.1 apply. 363 5.3.1.1. Examples 365 All the following examples (given as a specific URI mapping template, 366 a Target CoAP URI, and the produced Hosting HTTP URI) use 367 http://p.example.com/hc as the base URI. 369 1. "coap" URI is a query argument of the Hosting HTTP URI: 371 ?coap_target_uri={+cu} 373 coap://s.example.com/light 375 http://p.example.com/hc?coap_target_uri=coap://s.example.com/light 377 2. "coaps" URI is a query argument of the Hosting HTTP URI: 379 ?coaps_target_uri={+su} 381 coaps://s.example.com/light 383 http://p.example.com/hc?coaps_target_uri=coaps://s.example.com/light 385 3. Target CoAP URI as a query argument of the Hosting HTTP URI: 387 ?target_uri={+tu} 389 coap://s.example.com/light 391 http://p.example.com/hc?target_uri=coap://s.example.com/light 393 or 395 coaps://s.example.com/light 397 http://p.example.com/hc?target_uri=coaps://s.example.com/light 399 4. Target CoAP URI in the path component of the Hosting HTTP URI 400 (i.e., the default URI Mapping template): 402 /{+tu} 404 coap://s.example.com/light 406 http://p.example.com/hc/coap://s.example.com/light 408 or 410 coaps://s.example.com/light 412 http://p.example.com/hc/coaps://s.example.com/light 414 5.3.2. Enhanced Form 416 The enhanced form can be used to express more sophisticated mappings, 417 i.e., those that do not fit into the simple form. 419 There MUST be at most one instance of each of the following template 420 variables in a template definition: 422 s = "coap" / "coaps" ; from [RFC7252], Sections 6.1 and 6.2 423 hp = host [":" port] ; from [RFC3986] Sections 3.2.2 and 3.2.3 424 p = path-abempty ; from [RFC3986] Section 3.3. 425 q = [ "?" query ] ; from [RFC3986] Section 3.4 427 5.3.2.1. Examples 429 All the following examples (given as a specific URI mapping template, 430 a Target CoAP URI, and the produced Hosting HTTP URI) use 431 http://p.example.com/hc as the base URI. 433 1. Target CoAP URI components in path segments, and optional query 434 in query component: 436 {+s}{+hp}{+p}{+q} 438 coap://s.example.com/light 440 http://p.example.com/hc/coap/s.example.com/light 442 or 444 coap://s.example.com/light?on 446 http://p.example.com/hc/coap/s.example.com/light?on 448 2. Target CoAP URI components split in individual query arguments: 450 ?s={+s}&hp={+hp}&p={+p}&q={+q} 452 coap://s.example.com/light 454 http://p.example.com/hc?s=coap&hp=s.example.com&p=/light&q 456 or 458 coaps://s.example.com/light?on 460 http://p.example.com/hc?s=coaps&hp=s.example.com&p=/light&q=on 462 5.4. Discovery 464 In order to accommodate site specific needs while allowing third 465 parties to discover the proxy function, the HC Proxy SHOULD publish 466 information related to the location and syntax of the HC Proxy 467 function using the CoRE Link Format [RFC6690] interface. 469 To this aim a new Resource Type, "core.hc", is associated with a base 470 URI, and can be used as the value for the "rt" attribute in a query 471 to the /.well-known/core in order to locate the base URI where the HC 472 Proxy function is anchored. 474 Along with it, the new target attribute "hct" MAY be returned in a 475 "core.hc" link to provide the associated URI Mapping Template. The 476 default template given in Section 5.2, i.e., {+tu}, MUST be assumed 477 if no "hct" attribute is found in the returned link. If an "hct" 478 attribute is present in the returned link, then a compliant client 479 MUST use it to create the Hosting HTTP URI. 481 Discovery SHOULD be available on both the HTTP and the CoAP side of 482 the HC proxy, with one important difference: on the CoAP side the 483 link associated to the "core.hc" resource needs an explicit anchor 484 referring to the HTTP origin, while on the HTTP interface the link 485 context is already the HTTP origin carried in the request's Host 486 header, and doesn't have to be made explicit. 488 5.4.1. Examples 490 o The first example exercises the CoAP interface, and assumes that 491 the default template, {+tu}, is used: 493 Req: GET coap://[ff02::1]/.well-known/core?rt=core.hc 495 Res: 2.05 Content 496 ;anchor="http://p.example.com";rt="core.hc" 498 o The second example - also on the CoAP side of the HC Proxy - uses 499 a custom template, i.e., one where the CoAP URI is carried inside 500 the query component, thus the returned link carries the URI 501 template to be used in an explicit "hct" attribute: 503 Req: GET coap://[ff02::1]/.well-known/core?rt=core.hc 505 Res: 2.05 Content 506 ;anchor="http://p.example.com";rt="core.hc";hct="?uri={+tu}" 508 On the HTTP side link information can be serialised in more than one 509 way: 511 o using the 'application/link-format' content type: 513 Req: GET /.well-known/core?rt=core.hc HTTP/1.1 514 Host: p.example.com 516 Res: HTTP/1.1 200 OK 517 Content-Type: application/link-format 518 Content-Length: 18 520 ;rt="core.hc" 522 o using the 'application/link-format+json' content type: 524 Req: GET /.well-known/core?rt=core.hc HTTP/1.1 525 Host: p.example.com 527 Res: HTTP/1.1 200 OK 528 Content-Type: application/link-format+json 529 Content-Length: 31 531 [{"href":"/hc","rt":"core.hc"}] 533 o using the Link header: 535 Req: GET /.well-known/core?rt=core.hc HTTP/1.1 536 Host: p.example.com 538 Res: HTTP/1.1 200 OK 539 Link: ;rt="core.hc" 541 o An HC Proxy may expose two different base URIs to differentiate 542 between Target CoAP resources in the "coap" and "coaps" scheme: 544 Req: GET /.well-known/core?rt=core.hc 545 Host: p.example.com 547 Res: HTTP/1.1 200 OK 548 Content-Type: application/link-format+json 549 Content-Length: 111 551 [ 552 {"href":"/hc/plaintext","rt":"core.hc","hct":"{+cu}"}, 553 {"href":"/hc/secure","rt":"core.hc","hct":"{+su}"} 554 ] 556 6. HTTP-CoAP Reverse Proxy 558 A HTTP-CoAP Reverse Cross-Protocol Proxy is accessed by web clients 559 only supporting HTTP, and handles their requests by mapping these to 560 CoAP requests, which are forwarded to CoAP servers; and mapping back 561 the received CoAP responses to HTTP. This mechanism is transparent 562 to the client, which may assume that it is communicating with the 563 intended target HTTP server. In other words, the client accesses the 564 proxy as an origin server using the "origin-form" [RFC7230] as a 565 Request Target. 567 Normative requirements on the translation of HTTP requests to CoAP 568 and of the CoAP responses back to HTTP responses are defined in 569 Section 10.2 of [RFC7252]. However, that section only considers the 570 case of a HTTP-CoAP Forward Cross-Protocol Proxy in which a client 571 explicitly indicates it targets a request to a CoAP server, and does 572 not cover all aspects of proxy implementation in detail. The present 573 section provides guidelines and more details for the implementation 574 of a Reverse Cross-Protocol Proxy, which MAY be followed in addition 575 to the normative requirements. 577 Translation of unicast HTTP requests into multicast CoAP requests is 578 currently out of scope since in a reverse proxy scenario a HTTP 579 client typically expects to receive a single response, not multiple. 580 However a HC Proxy MAY include custom application-specific functions 581 to generate a multicast CoAP request based on a unicast HTTP request 582 and aggregate multiple CoAP responses into a single HTTP response. 584 Note that the guidelines in this section may also apply to an HTTP- 585 CoAP Intercepting Cross-Protocol Proxy. 587 6.1. Proxy Placement 589 Typically, a Cross-Protocol Proxy is located at the edge of the 590 constrained network. See Figure 1. The arguments supporting server- 591 side (SS) placement are the following: 593 Caching: Efficient caching requires that all request traffic to a 594 CoAP server is handled by the same proxy which receives HTTP 595 requests from multiple source locations. This maximally reduces 596 the load on (constrained) CoAP servers. 598 Multicast: To support CoAPs use of local-multicast functionality 599 available in a constrained network, the Cross-Protocol Proxy 600 requires a network interface directly attached to the constrained 601 network. 603 TCP/UDP: Translation between HTTP and CoAP requires also TCP/UDP 604 translation; TCP may be the preferred way for communicating with 605 the constrained network due to its reliability or due to 606 intermediate gateways configured to block UDP traffic. 608 Arguments against SS placement, in favor of client-side (CS), are: 610 Scalability: A solution where a single SS proxy has to manage 611 numerous open TCP/IP connections to a large number of HTTP clients 612 is not scalable. (Unless multiple SS proxies are employed with a 613 load-balancing mechanism, which adds complexity.) 614 +------+ 615 | | 616 | DNS | 617 | | 618 +------+ Constrained Network 619 -------------------- 620 / \ 621 / /-----\ /-----\ \ 622 / CoAP CoAP \ 623 / server server \ 624 || \-----/ \-----/ || 625 +------+ HTTP Request +----------+ || 626 |HTTP |------------------------>| HTTP-CoAP| Req /-----\ || 627 |Client| | Cross- |------->| CoAP || 628 | |<------------------------| Proxy |<-------|server || 629 +------+ HTTP Response +----------+ Resp \-----/ || 630 || || 631 || /-----\ || 632 || CoAP || 633 \ server / 634 \ \-----/ / 635 \ /-----\ / 636 \ CoAP / 637 \ server / 638 \ \-----/ / 639 ---------------- 641 Figure 1: Reverse Cross-Protocol Proxy Deployment Scenario 643 6.2. Response Code Translations 645 Table 1 defines the HTTP response to which each CoAP response SHOULD 646 be translated. This table complies with the Section 10.2 647 requirements of [RFC7252] and is intended to cover all possible 648 cases. Multiple appearances of a HTTP status code in the second 649 column indicates multiple equivalent HTTP responses are possible, 650 depending on the conditions cited in the Notes (third column). 652 +-----------------------------+-----------------------------+-------+ 653 | CoAP Response Code | HTTP Status Code | Notes | 654 +-----------------------------+-----------------------------+-------+ 655 | 2.01 Created | 201 Created | 1 | 656 | 2.02 Deleted | 200 OK | 2 | 657 | | 204 No Content | 2 | 658 | 2.03 Valid | 304 Not Modified | 3 | 659 | | 200 OK | 4 | 660 | 2.04 Changed | 200 OK | 2 | 661 | | 204 No Content | 2 | 662 | 2.05 Content | 200 OK | | 663 | 4.00 Bad Request | 400 Bad Request | | 664 | 4.01 Unauthorized | 400 Bad Request | 5 | 665 | 4.02 Bad Option | 400 Bad Request | 6 | 666 | 4.03 Forbidden | 403 Forbidden | | 667 | 4.04 Not Found | 404 Not Found | | 668 | 4.05 Method Not Allowed | 400 Bad Request | 7 | 669 | 4.06 Not Acceptable | 406 Not Acceptable | | 670 | 4.12 Precondition Failed | 412 Precondition Failed | | 671 | 4.13 Request Entity Too | 413 Request Repr. Too Large | | 672 | Large | | | 673 | 4.15 Unsupported Media Type | 415 Unsupported Media Type | | 674 | 5.00 Internal Server Error | 500 Internal Server Error | | 675 | 5.01 Not Implemented | 501 Not Implemented | | 676 | 5.02 Bad Gateway | 502 Bad Gateway | | 677 | 5.03 Service Unavailable | 503 Service Unavailable | 8 | 678 | 5.04 Gateway Timeout | 504 Gateway Timeout | | 679 | 5.05 Proxying Not Supported | 502 Bad Gateway | 9 | 680 +-----------------------------+-----------------------------+-------+ 682 Table 1: HTTP-CoAP Response Mapping 684 Notes: 686 1. A CoAP server may return an arbitrary format payload along with 687 this response. This payload SHOULD be returned as entity in the 688 HTTP 201 response. Section 7.3.2 of [RFC7231] does not put any 689 requirement on the format of the payload. (In the past, 690 [RFC2616] did.) 692 2. The HTTP code is 200 or 204 respectively for the case that a CoAP 693 server returns a payload or not. [RFC7231] Section 5.3 requires 694 code 200 in case a representation of the action result is 695 returned for DELETE, POST and PUT and code 204 if not. Hence, a 696 proxy SHOULD transfer any CoAP payload contained in a 2.02 697 response to the HTTP client in a 200 OK response. 699 3. A CoAP 2.03 (Valid) response only (1) confirms that the request 700 ETag is valid and (2) provides a new Max-Age value. HTTP 304 701 (Not Modified) also updates some header fields of a stored 702 response. A non-caching proxy may not have enough information to 703 fill in the required values in the HTTP 304 (Not Modified) 704 response, so it may not be advisable for a non-caching proxy to 705 provoke the 2.03 (Valid) response by forwarding an ETag. A 706 caching proxy will fill the information out of the cache. 708 4. A 200 response to a CoAP 2.03 occurs only when the proxy is 709 caching and translated a HTTP request (without validation 710 request) to a CoAP request that includes validation, for 711 efficiency. The proxy receiving 2.03 updates the freshness of 712 the cached representation and returns the entire representation 713 to the HTTP client. 715 5. The HTTP code 401 Unauthorized MUST NOT be used, as long as in 716 CoAP there is no equivalent defined of the required WWW- 717 Authenticate header (Section 3.1 of [RFC7235]). 719 6. In some cases a proxy receiving 4.02 may retry the request with 720 less CoAP Options in the hope that the server will understand the 721 newly formulated request. For example, if the proxy tried using 722 a Block Option which was not recognised by the CoAP server it may 723 retry without that Block Option. 725 7. The HTTP code "405 Method Not Allowed" MUST NOT be used since 726 CoAP does not provide enough information to determine a value for 727 the required "Allow" response-header field. 729 8. The value of the HTTP "Retry-After" response-header field is 730 taken from the value of the CoAP Max-Age Option, if present. 732 9. This CoAP response can only happen if the proxy itself is 733 configured to use a CoAP Forward Proxy to execute some, or all, 734 of its CoAP requests. 736 6.3. Media Type mapping 738 A HC Proxy translates HTTP media types (Section 3.1.1.1 of [RFC7231]) 739 and content encodings (Section 3.1.2.1 of [RFC7231]) into CoAP 740 content formats (Section 12.3 of [RFC7252]). 742 Media type translation can happen in GET, PUT or POST requests going 743 from HTTP to CoAP, and in 2.xx (i.e., successful) responses going 744 from CoAP to HTTP. Specifically, PUT and POST need to map the 745 Content-Type and Content-Encoding HTTP headers into a CoAP Content- 746 Format option, whereas GET needs to map Accept and Accept-Encoding 747 HTTP headers into a CoAP Accept option. On the way back, the CoAP 748 Content-Format option is renormalised into a suitable HTTP Content- 749 Type and Content-Encoding combination. 751 An HTTP request carrying a Content-Type and Content-Encoding 752 combination which the HC Proxy is unable to map to an equivalent CoAP 753 Content-Format, SHALL elicit a 415 (Unsupported Media Type) response 754 by the HC Proxy. 756 If the HC Proxy receives a CoAP response with a Content-Format that 757 it does not recognise (for example because the value has been 758 registered after the proxy has been deployed), then it is allowed to 759 either return a HTTP entity without a Content-Type header, or examine 760 the data to determine its type on the fly. 762 On the content negotiation side, failing to map Accept and Accept- 763 Encoding headers SHOULD be silently ignored: the HC Proxy SHOULD 764 therefore forward the request with no Accept option. 766 While the CoAP to HTTP direction has always a well defined mapping, 767 the HTTP to CoAP direction is more problematic because the source 768 set, i.e., potentially 1000+ IANA registered media types, is much 769 bigger than the destination set, i.e., the mere 6 values initially 770 defined in Section 12.3 of [RFC7252]. 772 Depending on the tight/loose coupling with the application(s) for 773 which it proxies, the HC Proxy could implement different media-type 774 mappings. 776 When tightly coupled, the HC Proxy knows exactly which content 777 formats are supported by the applications, and can be strict when 778 enforcing its forwarding policies in general, and the media-type 779 mapping in particular. 781 On the other side, when the HC Proxy is a general purpose application 782 layer gateway, being too strict could significantly reduce the amount 783 of traffic that it'd be able to successfully forward. In this cases, 784 the "loose" media-type mapping detailed in Section 6.3.1 MAY be 785 implemented. 787 The latter grants unconstrained evolution of the surrounding 788 ecosystem, at the cost of allowing more attack surface. In fact, as 789 a result of such strategy, payloads would be forwarded more liberally 790 across the unconstrained/constrained boundary of the communication 791 path. Therefore, when applied, other forms of access control must be 792 set in place to avoid unauthorised users to deplete or abuse systems 793 and network resources. 795 6.3.1. Loose Media Type Mapping 797 By structuring the type information in a super-class (e.g. "text") 798 followed by a finer grained sub-class (e.g. "html"), and optional 799 parameters (e.g. "charset=utf-8"), Internet media types provide a 800 rich and scalable framework for encoding the type of any given 801 entity. 803 This approach is not applicable to CoAP, where Content Formats 804 conflate an Internet media type (potentially with specific 805 parameters) and a content encoding into one small integer value. 807 To remedy this loss of flexibility, we introduce the concept of a 808 "loose" media type mapping, where media-types that are 809 specialisations of a more generic media-type can be aliased to their 810 super-class and then mapped (if possible) to one of CoAP content 811 formats. For example, "application/soap+xml" can be aliased to 812 "application/xml", which has a known conversion to CoAP. In the 813 context of this "loose" media type mapping, "application/octet- 814 stream" can be used as a fall back when no better alias is found for 815 a specific media-type. 817 Table 2 defines the default lookup table for the "loose" media-type 818 mapping. Given an input media-type, the table returns its best 819 generalised media-type using longest prefix match. 821 +---------------------+--------------------------+ 822 | Internet media-type | Generalised media-type | 823 +---------------------+--------------------------+ 824 | application/*+xml | application/xml | 825 | application/*+json | application/json | 826 | text/xml | application/xml | 827 | text/* | text/plain | 828 | */* | application/octet-stream | 829 +---------------------+--------------------------+ 831 Table 2: Media type generalisation 833 The "loose" media-type mapping is an OPTIONAL feature. 834 Implementations supporting this kind of mapping SHOULD provide a 835 flexible way to define the set of media-type generalisations allowed. 837 6.3.2. Internet Media Type to Content Format Mapping Algorithm 839 This section defines the algorithm used to map an HTTP Internet media 840 type to its correspondent CoAP content format. 842 The algorithm uses the mapping table defined in Section 12.3 of 843 [RFC7252] plus, possibly, any locally defined extension of it. 844 Optionally, the table and lookup mechanism described in Section 6.3.1 845 can be used if the implementation chooses so. 847 Note that the algorithm may have side effects on the associated 848 representation (see also Section 6.3.3). 850 In the following: 852 o C-T, C-E, and C-F stand for the values of the Content-Type (or 853 Accept) HTTP header, Content-Encoding (or Accept-Encoding) HTTP 854 header, and Content-Format CoAP option respectively. 856 o If C-E is not given it is assumed to be "identity". 858 o MAP is the mandatory lookup table, GMAP is the optional 859 generalised table. 861 INPUT: C-T and C-E 862 OUTPUT: C-F or Fail 864 1. if no C-T: return Fail 865 2. C-F = MAP[C-T, C-E] 866 3. if C-F is not None: return C-F 867 4. if C-E is not "identity": 868 5. if C-E is supported (e.g. gzip): 869 6. decode the representation accordingly 870 7. set C-E to "identity" 871 8. else: 872 9. return Fail 873 10. repeat steps 2. and 3. 874 11. if C-T allows a non-lossy transformation into \ 875 12. one of the supported C-F: 876 13. transcode the representation accordingly 877 14. return C-F 878 15. if GMAP is defined: 879 16. C-F = GMAP[C-T] 880 17. if C-F is not None: return C-F 881 18. return Fail 883 Figure 2 885 6.3.3. Content Transcoding 886 6.3.3.1. General 888 Payload content transcoding (e.g. see steps 11-14 of Figure 2) is an 889 OPTIONAL feature. Implementations supporting this feature should 890 provide a flexible way to define the set of transcodings allowed. 892 As noted in Section 6.3.2, the process of mapping the type of the 893 resource can have side effects on the forwarded entity body. This 894 may be caused by the removal or addition of a specific content 895 encoding, or because the HC Proxy decides to transcode the 896 representation to a different (compatible) format. The latter proves 897 useful when an optimised version of a specific format exists. For 898 example an XML-encoded resource could be transcoded to Efficient XML 899 Interchange (EXI) format, or a JSON-encoded resource into CBOR 900 [RFC7049], effectively achieving compression without losing any 901 information. 903 However, it should be noted that in certain cases, transcoding can 904 lose information in a non-obvious manner. For example, encoding an 905 XML document using schema-informed EXI encoding leads to a loss of 906 information when the destination does not know the exact schema 907 version used by the encoder. So whenever the HC Proxy transcodes an 908 application/XML to application/EXI in-band meta data could be lost. 909 Therefore, the implementer should always carefully verify such lossy 910 payload transformations before triggering the transcoding. 912 6.3.3.2. CoRE Link Format 914 The CoRE Link Format [RFC6690] is a set of links (i.e., URIs and 915 their formal relationships) which is carried as content payload in a 916 CoAP response. These links usually include CoAP URIs that might be 917 translated by the HC proxy to the correspondent HTTP URIs using the 918 implemented URI mapping function (see Section 5). Such a process 919 would inspect the forwarded traffic and attempt to re-write the body 920 of resources with an application/link-format media type, mapping the 921 embedded CoAP URIs to their HTTP counterparts. Some potential issues 922 with this approach are: 924 1. Tampering with payloads is incompatible with resources that are 925 integrity protected (although this is a problem with transcoding 926 in general). 928 2. The HC proxy needs to fully understand [RFC6690] syntax and 929 semantics, otherwise there is a inherent risk to corrupt the 930 payloads. 932 Therefore, CoRE Link Format payload should only be transcoded at the 933 risk and discretion of the proxy implementer. 935 6.3.3.3. Diagnostic Messages 937 CoAP responses may, in certain error cases, contain a diagnostic 938 message in the payload explaining the error situation, as described 939 in Section 5.5.2 of [RFC7252]. In this scenario, the CoAP response 940 diagnostic payload MUST NOT be returned as the regular HTTP payload 941 (message body). Instead, the CoAP diagnostic payload should be used 942 as the HTTP reason-phrase (of the HTTP status line as defined in 943 Section 3.1.2 of [RFC7230] ) without any alterations. 945 6.4. Caching and Congestion Control 947 A HC Proxy SHOULD limit the number of requests to CoAP servers by 948 responding, where applicable, with a cached representation of the 949 resource. 951 Duplicate idempotent pending requests by a HC Proxy to the same CoAP 952 resource SHOULD in general be avoided, by duplexing the response to 953 the requesting HTTP clients without duplicating the CoAP request. 955 If the HTTP client times out and drops the HTTP session to the HC 956 Proxy (closing the TCP connection) after the HTTP request was made, a 957 HC Proxy SHOULD wait for the associated CoAP response and cache it if 958 possible. Further requests to the HC Proxy for the same resource can 959 use the result present in cache, or, if a response has still to come, 960 the HTTP requests will wait on the open CoAP session. 962 According to [RFC7252], a proxy MUST limit the number of outstanding 963 interactions to a given CoAP server to NSTART. To limit the amount 964 of aggregate traffic to a constrained network, the HC Proxy SHOULD 965 also pose a limit to the number of concurrent CoAP requests pending 966 on the same constrained network; further incoming requests MAY either 967 be queued or dropped (returning 503 Service Unavailable). This limit 968 and the proxy queueing/dropping behavior SHOULD be configurable. In 969 order to efficiently apply this congestion control, the HC Proxy 970 SHOULD be SS placed. 972 Resources experiencing a high access rate coupled with high 973 volatility MAY be observed [I-D.ietf-core-observe] by the HC Proxy to 974 keep their cached representation fresh while minimizing the number 975 CoAP messages. See Section 6.5. 977 6.5. Cache Refresh via Observe 979 There are cases where using the CoAP observe protocol 980 [I-D.ietf-core-observe] to handle proxy cache refresh is preferable 981 to the validation mechanism based on ETag as defined in [RFC7252]. 982 Such scenarios include, but are not limited to, sleepy nodes -- with 983 possibly high variance in requests' distribution -- which would 984 greatly benefit from a server driven cache update mechanism. Ideal 985 candidates would also be crowded or very low throughput networks, 986 where reduction of the total number of exchanged messages is an 987 important requirement. 989 This subsection aims at providing a practical evaluation method to 990 decide whether the refresh of a cached resource R is more efficiently 991 handled via ETag validation or by establishing an observation on R. 993 Let T_R be the mean time between two client requests to resource R, 994 let F_R be the freshness lifetime of R representation, and let M_R be 995 the total number of messages exchanged towards resource R. If we 996 assume that the initial cost for establishing the observation is 997 negligible, an observation on R reduces M_R iff T_R < 2*F_R with 998 respect to using ETag validation, that is iff the mean arrival time 999 of requests for resource R is greater than half the refresh rate of 1000 R. 1002 When using observations M_R is always upper bounded by 2*F_R: in the 1003 constrained network no more than 2*F_R messages will be generated 1004 towards resource R. 1006 6.6. Use of CoAP Blockwise Transfer 1008 A HC Proxy SHOULD support CoAP blockwise transfers 1009 [I-D.ietf-core-block] to allow transport of large CoAP payloads while 1010 avoiding excessive link-layer fragmentation in LLNs, and to cope with 1011 small datagram buffers in CoAP end-points as described in [RFC7252] 1012 Section 4.6. 1014 A HC Proxy SHOULD attempt to retry a payload-carrying CoAP PUT or 1015 POST request with blockwise transfer if the destination CoAP server 1016 responded with 4.13 (Request Entity Too Large) to the original 1017 request. A HC Proxy SHOULD attempt to use blockwise transfer when 1018 sending a CoAP PUT or POST request message that is larger than a 1019 value BLOCKWISE_THRESHOLD. The value of BLOCKWISE_THRESHOLD MAY be 1020 implementation-specific, for example calculated based on a known or 1021 typical UDP datagram buffer size for CoAP end-points, or set to N 1022 times the size of a link-layer frame where e.g. N=5, or preset to a 1023 known IP MTU value, or set to a known Path MTU value. The value 1024 BLOCKWISE_THRESHOLD or parameters from which it is calculated SHOULD 1025 be configurable in a proxy implementation. 1027 The HC Proxy SHOULD detect CoAP end-points not supporting blockwise 1028 transfers by checking for a 4.02 (Bad Option) response returned by an 1029 end-point in response to a CoAP request with a Block* Option. This 1030 allows the HC Proxy to be more efficient, not attempting repeated 1031 blockwise transfers to CoAP servers that do not support it. However 1032 if a request payload is too large to be sent as a single CoAP request 1033 and blockwise transfer would be unavoidable, the proxy still SHOULD 1034 attempt blockwise transfer on such an end-point before returning 413 1035 (Request Entity Too Large) to the HTTP client. 1037 For improved latency a HC Proxy MAY initiate a blockwise CoAP request 1038 triggered by an incoming HTTP request even when the HTTP request 1039 message has not yet been fully received, but enough data has been 1040 received to send one or more data blocks to a CoAP server already. 1041 This is particularly useful on slow client-to-proxy connections. 1043 6.7. Security Translation 1045 A HC proxy SHOULD implement explicit rules for security context 1046 translations. A translation may involve e.g. applying a rule that 1047 any "https" request is translated to a "coaps" request, or e.g. 1048 applying a rule that a "https" request is translated to an unsecured 1049 "coap" request. Another rule could specify the security policy and 1050 parameters used for DTLS connections. Such rules will largely depend 1051 on the application and network context in which a proxy is applied. 1052 To enable widest possible use of a proxy implementation, these rules 1053 SHOULD be configurable in a HC proxy. 1055 If a policy for access to 'coaps' URIs is configurable in a HC proxy, 1056 it is RECOMMENDED that the policy is by default configured to 1057 disallow access to any 'coaps' URI by a HTTP client using an 1058 unsecured (non-TLS) connection. Naturally, a user MAY reconfigure 1059 the policy to allow such access in specific cases. 1061 6.8. Other guidelines 1063 For long delays of a CoAP server, the HTTP client or any other proxy 1064 in between MAY timeout. Further discussion of timeouts in HTTP is 1065 available in Section 6.2.4 of [RFC7230]. 1067 A HC Proxy MUST define an internal timeout for each pending CoAP 1068 request, because the CoAP server may silently die before completing 1069 the request. The timeout value SHOULD be approximately less than or 1070 equal to MAX_RTT defined in [RFC7252]. 1072 When the DNS protocol is not used between CoAP nodes in a constrained 1073 network, defining valid FQDN (i.e., DNS entries) for constrained CoAP 1074 servers, where possible, MAY help HTTP clients to access the 1075 resources offered by these servers via a HC proxy. 1077 HTTP connection pipelining (section 6.2.2.1 of [RFC7230]) MAY be 1078 supported by the proxy and is transparent to the CoAP network: the HC 1079 Proxy will sequentially serve the pipelined requests by issuing 1080 different CoAP requests. 1082 It is expected that the HC function will often be implemented in 1083 software on the proxy. Many different software approaches are 1084 possible, including using CGI [RFC3875] as an interface between the 1085 HTTP layer and the protocol translation engine. 1087 7. IANA Considerations 1089 This memo includes no request to IANA. 1091 8. Security Considerations 1093 The security concerns raised in Section 15.7 of [RFC2616] also apply 1094 to the HC Proxy scenario. In fact, the HC Proxy is a trusted (not 1095 rarely a transparently trusted) component in the network path. 1097 The trustworthiness assumption on the HC Proxy cannot be dropped. 1098 Even if we had a blind, bi-directional, end-to-end, tunneling 1099 facility like the one provided by the CONNECT method in HTTP, and 1100 also assuming the existence of a DTLS-TLS transparent mapping, the 1101 two tunneled ends should be speaking the same application protocol, 1102 which is not the case. Basically, the protocol translation function 1103 is a core duty of the HC Proxy that can't be removed, and makes it a 1104 necessarily trusted, impossible to bypass, component in the 1105 communication path. 1107 A reverse proxy deployed at the boundary of a constrained network is 1108 an easy single point of failure for reducing availability. As such, 1109 a special care should be taken in designing, developing and operating 1110 it, keeping in mind that, in most cases, it could have fewer 1111 limitations than the constrained devices it is serving. 1113 The following sub paragraphs categorize and argue about a set of 1114 specific security issues related to the translation, caching and 1115 forwarding functionality exposed by a HC Proxy module. 1117 8.1. Traffic overflow 1119 Due to the typically constrained nature of CoAP nodes, particular 1120 attention SHOULD be posed in the implementation of traffic reduction 1121 mechanisms (see Section 6.4), because inefficient implementations can 1122 be targeted by unconstrained Internet attackers. Bandwidth or 1123 complexity involved in such attacks is very low. 1125 An amplification attack to the constrained network may be triggered 1126 by a multicast request generated by a single HTTP request mapped to a 1127 CoAP multicast resource, as considered in Section TBD of [RFC7252]. 1129 The impact of this amplification technique is higher than an 1130 amplification attack carried out by a malicious constrained device 1131 (e.g. ICMPv6 flooding, like Packet Too Big, or Parameter Problem on 1132 a multicast destination [RFC4732]), since it does not require direct 1133 access to the constrained network. 1135 The feasibility of this attack, disruptive in terms of CoAP server 1136 availability, can be limited by access controlling the exposed HTTP 1137 multicast resource, so that only known/authorized users access such 1138 URIs. 1140 8.2. Handling Secured Exchanges 1142 It is possible that the request from the client to the HC Proxy is 1143 sent over a secured connection. However, there may or may not exist 1144 a secure connection mapping to the other protocol. For example, a 1145 secure distribution method for multicast traffic is complex and MAY 1146 not be implemented (see [I-D.ietf-core-groupcomm]). 1148 By default, a HC Proxy SHOULD reject any secured client request if 1149 there is no configured security policy mapping. This recommendation 1150 MAY be relaxed in case the destination network is believed to be 1151 secured by other, complementary, means. E.g.: assumed that CoAP 1152 nodes are isolated behind a firewall (e.g. as the SS HC proxy 1153 deployment shown in Figure 1), the HC Proxy may be configured to 1154 translate the incoming HTTPS request using plain CoAP (i.e., NoSec 1155 mode.) 1157 The HC URI mapping MUST NOT map to HTTP (see Section 5) a CoAP 1158 resource intended to be accessed only using HTTPS. 1160 A secured connection that is terminated at the HC Proxy, i.e., the 1161 proxy decrypts secured data locally, raises an ambiguity about the 1162 cacheability of the requested resource. The HC Proxy SHOULD NOT 1163 cache any secured content to avoid any leak of secured information. 1164 However in some specific scenario, a security/efficiency trade-off 1165 could motivate caching secured information; in that case the caching 1166 behavior MAY be tuned to some extent on a per-resource basis. 1168 8.3. URI Mapping 1170 The following risks related to the URI mapping described in Section 5 1171 have been identified: 1173 DoS attack on the internal network. 1174 Default deny any Target CoAP URI whose authority is (or maps to) a 1175 multicast address. Then explicitly whitelist multicast resources 1176 that are allowed to be de-referenced. 1178 Leaking information on the internal network resources and topology. 1179 Default deny any Target CoAP URI (especially /.well-known/core is 1180 the resource to be protected), and then explicit whitelist 1181 resources that are allowed to be seen from outside. 1183 Reduced privacy due to the mechanics of the URI mapping. 1184 The internal CoAP Target resource is totally transparent from 1185 outside: an HC Proxy implementing a HTTPS-only interface makes the 1186 Target CoAP URI totally opaque to a passive attacker. 1188 9. Acknowledgements 1190 An initial version of the table found in Section 6.2 has been 1191 provided in revision -05 of [RFC7252]. Special thanks to Peter van 1192 der Stok for countless comments and discussions on this document, 1193 that contributed to its current structure and text. 1195 Thanks to Carsten Bormann, Zach Shelby, Michele Rossi, Nicola Bui, 1196 Michele Zorzi, Klaus Hartke, Cullen Jennings, Kepeng Li, Brian Frank, 1197 Peter Saint-Andre, Kerry Lynn, Linyi Tian, Dorothy Gellert, Francesco 1198 Corazza for helpful comments and discussions that have shaped the 1199 document. 1201 The research leading to these results has received funding from the 1202 European Community's Seventh Framework Programme [FP7/2007-2013] 1203 under grant agreement n. [251557]. 1205 10. References 1207 10.1. Normative References 1209 [I-D.ietf-core-block] 1210 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1211 draft-ietf-core-block-15 (work in progress), July 2014. 1213 [I-D.ietf-core-observe] 1214 Hartke, K., "Observing Resources in CoAP", draft-ietf- 1215 core-observe-14 (work in progress), June 2014. 1217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1218 Requirement Levels", BCP 14, RFC 2119, March 1997. 1220 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1221 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1222 3986, January 2005. 1224 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 1225 and D. Orchard, "URI Template", RFC 6570, March 2012. 1227 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1228 Format", RFC 6690, August 2012. 1230 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1231 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1232 2014. 1234 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1235 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1237 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1238 (HTTP/1.1): Authentication", RFC 7235, June 2014. 1240 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1241 Application Protocol (CoAP)", RFC 7252, June 2014. 1243 10.2. Informative References 1245 [I-D.ietf-core-groupcomm] 1246 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1247 draft-ietf-core-groupcomm-25 (work in progress), September 1248 2014. 1250 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1251 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1252 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1254 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 1255 Replication and Caching Taxonomy", RFC 3040, January 2001. 1257 [RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface 1258 (CGI) Version 1.1", RFC 3875, October 2004. 1260 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1261 Service Considerations", RFC 4732, December 2006. 1263 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1264 Representation (CBOR)", RFC 7049, October 2013. 1266 Appendix A. Change Log 1268 [Note to RFC Editor: Please remove this section before publication.] 1270 Changes from ietf-04 to ietf-05: 1272 o Addressed Ticket #366 (Mapping of CoRE Link Format payloads to be 1273 valid in HTTP Domain?) in section 6.3.3.2 (Content Transcoding - 1274 CORE Link Format); 1276 o Addressed Ticket #375 (Add requirement on mapping of CoAP 1277 diagnostic payload) in section 6.3.3.3 (Content Transcoding - 1278 Diagnostic Messages); 1280 o Addressed comment from Yusuke (http://www.ietf.org/mail- 1281 archive/web/core/current/msg05491.html) in section 6.3.3.1 1282 (Content Transcoding - General); 1284 o Various editorial improvements. 1286 Changes from ietf-03 to ietf-04: 1288 o Expanded use case descriptions in Section 4; 1290 o Fixed/enhanced discovery examples in Section 5.4.1; 1292 o Addressed Ticket #365 (Add text on media-type conversion by HTTP- 1293 CoAP proxy) in new section 6.3.1 (Generalized media-type mapping) 1294 and new section 6.3.2 (Content translation); 1296 o Updated HTTPBis WG draft references to recently published RFC 1297 numbers. 1299 o Various editorial improvements. 1301 Changes from ietf-02 to ietf-03: 1303 o Closed Ticket #351 "Add security implications of proposed default 1304 HC URI mapping"; 1306 o Closed Ticket #363 "Remove CoAP scheme in default HTTP-CoAP URI 1307 mapping"; 1309 o Closed Ticket #364 "Add discovery of HTTP-CoAP mapping 1310 resource(s)". 1312 Changes from ietf-01 to ietf-02: 1314 o Selection of single default URI mapping proposal as proposed to WG 1315 mailing list 2013-10-09. 1317 Changes from ietf-00 to ietf-01: 1319 o Added URI mapping proposals to Section 4 as per the Email 1320 proposals to WG mailing list from Esko. 1322 Authors' Addresses 1324 Angelo P. Castellani 1325 University of Padova 1326 Via Gradenigo 6/B 1327 Padova 35131 1328 Italy 1330 Email: angelo@castellani.net 1332 Salvatore Loreto 1333 Ericsson 1334 Hirsalantie 11 1335 Jorvas 02420 1336 Finland 1338 Email: salvatore.loreto@ericsson.com 1340 Akbar Rahman 1341 InterDigital Communications, LLC 1342 1000 Sherbrooke Street West 1343 Montreal H3A 3G4 1344 Canada 1346 Phone: +1 514 585 0761 1347 Email: Akbar.Rahman@InterDigital.com 1349 Thomas Fossati 1350 Alcatel-Lucent 1351 3 Ely Road 1352 Milton, Cambridge CB24 6DD 1353 UK 1355 Email: thomas.fossati@alcatel-lucent.com 1356 Esko Dijk 1357 Philips Research 1358 High Tech Campus 34 1359 Eindhoven 5656 AE 1360 The Netherlands 1362 Email: esko.dijk@philips.com