idnits 2.17.1 draft-ietf-core-http-mapping-04.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 (July 4, 2014) is 3578 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 880, but not defined == Missing Reference: 'C-E' is mentioned on line 866, but not defined -- Looks like a reference, but probably isn't: '251557' on line 1161 == Unused Reference: 'RFC6570' is defined on line 1182, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-core-block-12 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-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) == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-19 -- 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 (~~), 7 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: January 5, 2015 Ericsson 6 A. Rahman 7 InterDigital Communications, LLC 8 T. Fossati 9 Alcatel-Lucent 10 E. Dijk 11 Philips Research 12 July 4, 2014 14 Guidelines for HTTP-CoAP Mapping Implementations 15 draft-ietf-core-http-mapping-04 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 January 5, 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 . . . . . . . . . . . . . 20 82 6.5. Cache Refresh via Observe . . . . . . . . . . . . . . . . 21 83 6.6. Use of CoAP Blockwise Transfer . . . . . . . . . . . . . 21 84 6.7. Security Translation . . . . . . . . . . . . . . . . . . 22 85 6.8. Other guidelines . . . . . . . . . . . . . . . . . . . . 22 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 88 8.1. Traffic overflow . . . . . . . . . . . . . . . . . . . . 24 89 8.2. Handling Secured Exchanges . . . . . . . . . . . . . . . 24 90 8.3. URI Mapping . . . . . . . . . . . . . . . . . . . . . . . 25 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 94 10.2. Informative References . . . . . . . . . . . . . . . . . 26 95 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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 This document assumes readers are familiar with the terms Reverse 147 Proxy as defined in [RFC7230] and Interception Proxy as defined in 148 [RFC3040]. In addition, the following terms are defined: 150 HC Proxy: is a proxy performing a cross-protocol mapping, in the 151 context of this document a HTTP-CoAP (HC) mapping. A Cross-Protocol 152 Proxy can behave as a Forward Proxy, Reverse Proxy or Interception 153 Proxy. Note: In this document we focus on the Reverse Proxy mode of 154 the Cross-Protocol Proxy. 156 Forward Proxy: a message forwarding agent that is selected by the 157 client, usually via local configuration rules, to receive requests 158 for some type(s) of absolute URI and to attempt to satisfy those 159 requests via translation to the protocol indicated by the absolute 160 URI. The user decides (is willing to) use the proxy as the 161 forwarding/dereferencing agent for a predefined subset of the URI 162 space. 164 Reverse Proxy: a receiving agent that acts as a layer above some 165 other server(s) and translates the received requests to the 166 underlying server's protocol. It behaves as an origin (HTTP) server 167 on its connection towards the (HTTP) client and as a (CoAP) client on 168 its connection towards the (CoAP) origin server. The (HTTP) client 169 uses the "origin-form" [RFC7230] as a request-target URI. 171 Reverse and Forward proxies are technically very similar, with main 172 differences being that the former appears to a client as an origin 173 server while the latter does not, and that clients may be unaware 174 they are communicating with a proxy. 176 Placement terms: a server-side (SS) proxy is placed in the same 177 network domain as the server; conversely a client-side (CS) proxy is 178 in the same network domain as the client. In any other case than SS 179 or CS, the proxy is said to be External (E). 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in 184 [RFC2119]. 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 URIs 199 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: Any 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 can be built providing a friendlier 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 if 477 no "hct" attribute is found in the returned link. If an "htc" 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","htc":"{+cu}"}, 553 {"href":"/hc/secure","rt":"core.hc","htc":"{+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 also apply to an HTTP-CoAP 585 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 all possible CoAP responses along with the HTTP 646 response to which each CoAP response SHOULD be translated. This 647 table complies with the Section 10.2 requirements of [RFC7252] and is 648 intended to cover all possible cases. Multiple appearances of a HTTP 649 status code in the second column indicates multiple equivalent HTTP 650 responses are possible, depending on the conditions cited in the 651 Notes (third column). 653 +-----------------------------+-----------------------------+-------+ 654 | CoAP Response Code | HTTP Status Code | Notes | 655 +-----------------------------+-----------------------------+-------+ 656 | 2.01 Created | 201 Created | 1 | 657 | 2.02 Deleted | 200 OK | 2 | 658 | | 204 No Content | 2 | 659 | 2.03 Valid | 304 Not Modified | 3 | 660 | | 200 OK | 4 | 661 | 2.04 Changed | 200 OK | 2 | 662 | | 204 No Content | 2 | 663 | 2.05 Content | 200 OK | | 664 | 4.00 Bad Request | 400 Bad Request | | 665 | 4.01 Unauthorized | 400 Bad Request | 5 | 666 | 4.02 Bad Option | 400 Bad Request | 6 | 667 | 4.03 Forbidden | 403 Forbidden | | 668 | 4.04 Not Found | 404 Not Found | | 669 | 4.05 Method Not Allowed | 400 Bad Request | 7 | 670 | 4.06 Not Acceptable | 406 Not Acceptable | | 671 | 4.12 Precondition Failed | 412 Precondition Failed | | 672 | 4.13 Request Entity Too | 413 Request Repr. Too Large | | 673 | Large | | | 674 | 4.15 Unsupported Media Type | 415 Unsupported Media Type | | 675 | 5.00 Internal Server Error | 500 Internal Server Error | | 676 | 5.01 Not Implemented | 501 Not Implemented | | 677 | 5.02 Bad Gateway | 502 Bad Gateway | | 678 | 5.03 Service Unavailable | 503 Service Unavailable | 8 | 679 | 5.04 Gateway Timeout | 504 Gateway Timeout | | 680 | 5.05 Proxying Not Supported | 502 Bad Gateway | 9 | 681 +-----------------------------+-----------------------------+-------+ 683 Table 1: HTTP-CoAP Response Mapping 685 Notes: 687 1. A CoAP server may return an arbitrary format payload along with 688 this response. This payload SHOULD be returned as entity in the 689 HTTP 201 response. Section 7.3.2 of [RFC7231] does not put any 690 requirement on the format of the payload. (In the past, 691 [RFC2616] did.) 693 2. The HTTP code is 200 or 204 respectively for the case that a CoAP 694 server returns a payload or not. [RFC7231] Section 5.3 requires 695 code 200 in case a representation of the action result is 696 returned for DELETE, POST and PUT and code 204 if not. Hence, a 697 proxy SHOULD transfer any CoAP payload contained in a 2.02 698 response to the HTTP client in a 200 OK response. 700 3. A CoAP 2.03 (Valid) response only (1) confirms that the request 701 ETag is valid and (2) provides a new Max-Age value. HTTP 304 702 (Not Modified) also updates some header fields of a stored 703 response. A non-caching proxy may not have enough information to 704 fill in the required values in the HTTP 304 (Not Modified) 705 response, so it may not be advisable for a non-caching proxy to 706 provoke the 2.03 (Valid) response by forwarding an ETag. A 707 caching proxy will fill the information out of the cache. 709 4. A 200 response to a CoAP 2.03 occurs only when the proxy is 710 caching and translated a HTTP request (without validation 711 request) to a CoAP request that includes validation, for 712 efficiency. The proxy receiving 2.03 updates the freshness of 713 the cached representation and returns the entire representation 714 to the HTTP client. 716 5. The HTTP code 401 Unauthorized MUST NOT be used, as long as in 717 CoAP there is no equivalent defined of the required WWW- 718 Authenticate header (Section 3.1 of [RFC7235]). 720 6. In some cases a proxy receiving 4.02 may retry the request with 721 less CoAP Options in the hope that the server will understand the 722 newly formulated request. For example, if the proxy tried using 723 a Block Option which was not recognised by the CoAP server it may 724 retry without that Block Option. 726 7. The HTTP code "405 Method Not Allowed" MUST NOT be used since 727 CoAP does not provide enough information to determine a value for 728 the required "Allow" response-header field. 730 8. The value of the HTTP "Retry-After" response-header field is 731 taken from the value of the CoAP Max-Age Option, if present. 733 9. This CoAP response can only happen if the proxy itself is 734 configured to use a CoAP Forward Proxy to execute some, or all, 735 of its CoAP requests. 737 6.3. Media Type mapping 739 A HC Proxy translates HTTP media types (Section 3.1.1.1 of [RFC7231]) 740 and content encodings (Section 3.1.2.1 of [RFC7231]) into CoAP 741 content formats (Section 12.3 of [RFC7252]). 743 Media type translation can happen in GET, PUT or POST requests going 744 from HTTP to CoAP, and in 2.xx (i.e. successful) responses going from 745 CoAP to HTTP. Specifically, PUT and POST need to map the Content- 746 Type and Content-Encoding HTTP headers into a CoAP Content-Format 747 option, whereas GET needs to map Accept and Accept-Encoding HTTP 748 headers into a CoAP Accept option. On the way back, the CoAP 749 Content-Format option is renormalised into a suitable HTTP Content- 750 Type and Content-Encoding combination. 752 An HTTP request carrying a Content-Type and Content-Encoding 753 combination which the HC Proxy is unable to map to an equivalent CoAP 754 Content-Format, SHALL elicit a 415 (Unsupported Media Type) response 755 by the HC Proxy. 757 If the HC Proxy receives a CoAP response with a Content-Format that 758 it does not recognise (for example because the value has been 759 registered after the proxy has been deployed), then it is allowed to 760 either return a HTTP entity without a Content-Type header, or examine 761 the data to determine its type on the fly. 763 On the content negotiation side, failing to map Accept and Accept- 764 Encoding headers SHOULD be silently ignored: the HC Proxy SHOULD 765 therefore forward the request with no Accept option. 767 While the CoAP to HTTP direction has always a well defined mapping, 768 the HTTP to CoAP direction is more problematic because the source 769 set, i.e., potentially 1000+ IANA registered media types, is much 770 bigger than the destination set, i.e. the mere 6 values initially 771 defined in Section 12.3 of [RFC7252]. 773 Depending on the tight/loose coupling with the application(s) for 774 which it proxies, the HC Proxy could implement different media-type 775 mappings. 777 When tightly coupled, the HC Proxy knows exactly which content 778 formats are supported by the applications, and can be strict when 779 enforcing its forwarding policies in general, and the media-type 780 mapping in particular. 782 On the other side, when the HC Proxy is a general purpose application 783 layer gateway, being too strict could significantly reduce the amount 784 of traffic that it'd be able to successfully forward. In this cases, 785 the "loose" media-type mapping detailed in Section 6.3.1 MAY be 786 implemented. 788 The latter grants unconstrained evolution of the surrounding 789 ecosystem, at the cost of allowing more attack surface. In fact, as 790 a result of such strategy, payloads would be forwarded more liberally 791 across the unconstrained/constrained boundary of the communication 792 path. Therefore, when applied, other forms of access control must be 793 set in place to avoid unauthorised users to deplete or abuse systems 794 and network resources. 796 6.3.1. Loose Media Type Mapping 798 By structuring the type information in a super-class (e.g. "text") 799 followed by a finer grained sub-class (e.g. "html"), and optional 800 parameters (e.g. "charset=utf-8"), Internet media types provide a 801 rich and scalable framework for encoding the type of any given 802 entity. 804 This approach is not applicable to CoAP, where Content Formats 805 conflate an Internet media type (potentially with specific 806 parameters) and a content encoding into one small integer value. 808 To remedy this loss of flexibility, we introduce the concept of a 809 "loose" media type mapping, where media-types that are 810 specialisations of a more generic media-type can be aliased to their 811 super-class and then mapped (if possible) to one of CoAP content 812 formats. For example, "application/soap+xml" can be aliased to 813 "application/xml", which has a known conversion to CoAP. In the 814 context of this "loose" media type mapping, "application/octet- 815 stream" can be used as a fall back when no better alias is found for 816 a specific media-type. 818 Table 2 defines the default lookup table for the "loose" media-type 819 mapping. Given an input media-type, the table returns its best 820 generalised media-type using longest prefix match. 822 +---------------------+--------------------------+ 823 | Internet media-type | Generalised media-type | 824 +---------------------+--------------------------+ 825 | application/*+xml | application/xml | 826 | application/*+json | application/json | 827 | text/xml | application/xml | 828 | text/* | text/plain | 829 | */* | application/octet-stream | 830 +---------------------+--------------------------+ 832 Table 2: Media type generalisation 834 The "loose" media-type mapping is an OPTIONAL feature. 835 Implementations supporting this kind of mapping SHOULD provide a 836 flexible way to define the set of media-type generalisations allowed. 838 6.3.2. Internet Media Type to Content Format Mapping Algorithm 840 This section defines the algorithm used to map an Internet media type 841 to its correspondent CoAP content format. 843 The algorithm uses the mapping table defined in Section 12.3 of 844 [RFC7252] plus, possibly, any locally defined extension of it. 845 Optionally, the table and lookup mechanism described in Section 6.3.1 846 can be used if the implementation chooses so. 848 Note that the algorithm may have side effects on the associated 849 representation (see also Section 6.3.3). 851 In the following: 853 o C-T, C-E, and C-F stand for the values of the Content-Type (or 854 Accept), Content-Encoding (or Accept-Encoding) HTTP headers, and 855 Content-Format CoAP option respectively. 857 o If C-E is not given it is assumed to be "identity". 859 o MAP is the mandatory lookup table, GMAP is the optional 860 generalised table. 862 INPUT: C-T and C-E 863 OUTPUT: C-F or Fail 865 1. if no C-T: return Fail 866 2. C-F = MAP[C-T, C-E] 867 3. if C-F is not None: return C-F 868 4. if C-E is not "identity": 869 5. if C-E is supported (e.g. gzip): 870 6. decode the representation accordingly 871 7. set C-E to "identity" 872 8. else: 873 9. return Fail 874 10. repeat steps 2. and 3. 875 11. if C-T allows a non-lossy transformation into \ 876 12. one of the supported C-F: 877 13. transcode the representation accordingly 878 14. return C-F 879 15. if GMAP is defined: 880 16. C-F = GMAP[C-T] 881 17. if C-F is not None: return C-F 882 18. return Fail 884 Figure 2 886 6.3.3. Content Transcoding 888 As noted in Section 6.3.2, the process of mapping the type of the 889 resource can have side effects on the forwarded entity body. 891 This may be caused by the removal or addition of a specific content 892 encoding, or because the HC Proxy decides to transcode the 893 representation to a different (compatible) format. The latter proves 894 useful when an optimised version of a specific format exists. For 895 example an XML-encoded resource could be transcoded to EXI, or a 896 JSON-encoded resource into CBOR [RFC7049], effectively achieving 897 compression without losing any information. 899 Payload transcoding (see steps 11-14 of Figure 2) is an OPTIONAL 900 feature. Implementations supporting this feature SHOULD provide a 901 flexible way to define the set of transcodings allowed. 903 6.4. Caching and Congestion Control 905 A HC Proxy SHOULD limit the number of requests to CoAP servers by 906 responding, where applicable, with a cached representation of the 907 resource. 909 Duplicate idempotent pending requests by a HC Proxy to the same CoAP 910 resource SHOULD in general be avoided, by duplexing the response to 911 the requesting HTTP clients without duplicating the CoAP request. 913 If the HTTP client times out and drops the HTTP session to the HC 914 Proxy (closing the TCP connection) after the HTTP request was made, a 915 HC Proxy SHOULD wait for the associated CoAP response and cache it if 916 possible. Further requests to the HC Proxy for the same resource can 917 use the result present in cache, or, if a response has still to come, 918 the HTTP requests will wait on the open CoAP session. 920 According to [RFC7252], a proxy MUST limit the number of outstanding 921 interactions to a given CoAP server to NSTART. To limit the amount 922 of aggregate traffic to a constrained network, the HC Proxy SHOULD 923 also pose a limit to the number of concurrent CoAP requests pending 924 on the same constrained network; further incoming requests MAY either 925 be queued or dropped (returning 503 Service Unavailable). This limit 926 and the proxy queueing/dropping behavior SHOULD be configurable. In 927 order to efficiently apply this congestion control, the HC Proxy 928 SHOULD be SS placed. 930 Resources experiencing a high access rate coupled with high 931 volatility MAY be observed [I-D.ietf-core-observe] by the HC Proxy to 932 keep their cached representation fresh while minimizing the number 933 CoAP messages. See Section 6.5. 935 6.5. Cache Refresh via Observe 937 There are cases where using the CoAP observe protocol 938 [I-D.ietf-core-observe] to handle proxy cache refresh is preferable 939 to the validation mechanism based on ETag as defined in [RFC7252]. 940 Such scenarios include, but are not limited to, sleepy nodes -- with 941 possibly high variance in requests' distribution -- which would 942 greatly benefit from a server driven cache update mechanism. Ideal 943 candidates would also be crowded or very low throughput networks, 944 where reduction of the total number of exchanged messages is an 945 important requirement. 947 This subsection aims at providing a practical evaluation method to 948 decide whether the refresh of a cached resource R is more efficiently 949 handled via ETag validation or by establishing an observation on R. 951 Let T_R be the mean time between two client requests to resource R, 952 let F_R be the freshness lifetime of R representation, and let M_R be 953 the total number of messages exchanged towards resource R. If we 954 assume that the initial cost for establishing the observation is 955 negligible, an observation on R reduces M_R iff T_R < 2*F_R with 956 respect to using ETag validation, that is iff the mean arrival time 957 of requests for resource R is greater than half the refresh rate of 958 R. 960 When using observations M_R is always upper bounded by 2*F_R: in the 961 constrained network no more than 2*F_R messages will be generated 962 towards resource R. 964 6.6. Use of CoAP Blockwise Transfer 966 A HC Proxy SHOULD support CoAP blockwise transfers 967 [I-D.ietf-core-block] to allow transport of large CoAP payloads while 968 avoiding excessive link-layer fragmentation in LLNs, and to cope with 969 small datagram buffers in CoAP end-points as described in [RFC7252] 970 Section 4.6. 972 A HC Proxy SHOULD attempt to retry a payload-carrying CoAP PUT or 973 POST request with blockwise transfer if the destination CoAP server 974 responded with 4.13 (Request Entity Too Large) to the original 975 request. A HC Proxy SHOULD attempt to use blockwise transfer when 976 sending a CoAP PUT or POST request message that is larger than a 977 value BLOCKWISE_THRESHOLD. The value of BLOCKWISE_THRESHOLD MAY be 978 implementation-specific, for example calculated based on a known or 979 typical UDP datagram buffer size for CoAP end-points, or set to N 980 times the size of a link-layer frame where e.g. N=5, or preset to a 981 known IP MTU value, or set to a known Path MTU value. The value 982 BLOCKWISE_THRESHOLD or parameters from which it is calculated SHOULD 983 be configurable in a proxy implementation. 985 The HC Proxy SHOULD detect CoAP end-points not supporting blockwise 986 transfers by checking for a 4.02 (Bad Option) response returned by an 987 end-point in response to a CoAP request with a Block* Option. This 988 allows the HC Proxy to be more efficient, not attempting repeated 989 blockwise transfers to CoAP servers that do not support it. However 990 if a request payload is too large to be sent as a single CoAP request 991 and blockwise transfer would be unavoidable, the proxy still SHOULD 992 attempt blockwise transfer on such an end-point before returning 413 993 (Request Entity Too Large) to the HTTP client. 995 For improved latency a HC Proxy MAY initiate a blockwise CoAP request 996 triggered by an incoming HTTP request even when the HTTP request 997 message has not yet been fully received, but enough data has been 998 received to send one or more data blocks to a CoAP server already. 999 This is particularly useful on slow client-to-proxy connections. 1001 6.7. Security Translation 1003 A HC proxy SHOULD implement explicit rules for security context 1004 translations. A translation may involve e.g. applying a rule that 1005 any "https" request is translated to a "coaps" request, or e.g. 1006 applying a rule that a "https" request is translated to an unsecured 1007 "coap" request. Another rule could specify the security policy and 1008 parameters used for DTLS connections. Such rules will largely depend 1009 on the application and network context in which a proxy is applied. 1010 To enable widest possible use of a proxy implementation, these rules 1011 SHOULD be configurable in a HC proxy. 1013 If a policy for access to 'coaps' URIs is configurable in a HC proxy, 1014 it is RECOMMENDED that the policy is by default configured to 1015 disallow access to any 'coaps' URI by a HTTP client using an 1016 unsecured (non-TLS) connection. Naturally, a user MAY reconfigure 1017 the policy to allow such access in specific cases. 1019 6.8. Other guidelines 1021 For long delays of a CoAP server, the HTTP client or any other proxy 1022 in between MAY timeout. Further discussion of timeouts in HTTP is 1023 available in Section 6.2.4 of [RFC7230]. 1025 A HC Proxy MUST define an internal timeout for each pending CoAP 1026 request, because the CoAP server may silently die before completing 1027 the request. The timeout value SHOULD be approximately less than or 1028 equal to MAX_RTT defined in [RFC7252]. 1030 When the DNS protocol is not used between CoAP nodes in a constrained 1031 network, defining valid FQDN (i.e., DNS entries) for constrained CoAP 1032 servers, where possible, MAY help HTTP clients to access the 1033 resources offered by these servers via a HC proxy. 1035 HTTP connection pipelining (section 6.2.2.1 of [RFC7230]) MAY be 1036 supported by the proxy and is transparent to the CoAP network: the HC 1037 Proxy will sequentially serve the pipelined requests by issuing 1038 different CoAP requests. 1040 It is expected that the HC function will often be implemented in 1041 software on the proxy. Many different software approaches are 1042 possible, including using CGI [RFC3875] as an interface between the 1043 HTTP layer and the protocol translation engine. 1045 7. IANA Considerations 1047 This memo includes no request to IANA. 1049 8. Security Considerations 1051 The security concerns raised in Section 15.7 of [RFC2616] also apply 1052 to the HC Proxy scenario. In fact, the HC Proxy is a trusted (not 1053 rarely a transparently trusted) component in the network path. 1055 The trustworthiness assumption on the HC Proxy cannot be dropped. 1056 Even if we had a blind, bi-directional, end-to-end, tunneling 1057 facility like the one provided by the CONNECT method in HTTP, and 1058 also assuming the existence of a DTLS-TLS transparent mapping, the 1059 two tunneled ends should be speaking the same application protocol, 1060 which is not the case. Basically, the protocol translation function 1061 is a core duty of the HC Proxy that can't be removed, and makes it a 1062 necessarily trusted, impossible to bypass, component in the 1063 communication path. 1065 A reverse proxy deployed at the boundary of a constrained network is 1066 an easy single point of failure for reducing availability. As such, 1067 a special care should be taken in designing, developing and operating 1068 it, keeping in mind that, in most cases, it could have fewer 1069 limitations than the constrained devices it is serving. 1071 The following sub paragraphs categorize and argue about a set of 1072 specific security issues related to the translation, caching and 1073 forwarding functionality exposed by a HC Proxy module. 1075 8.1. Traffic overflow 1077 Due to the typically constrained nature of CoAP nodes, particular 1078 attention SHOULD be posed in the implementation of traffic reduction 1079 mechanisms (see Section 6.4), because inefficient implementations can 1080 be targeted by unconstrained Internet attackers. Bandwidth or 1081 complexity involved in such attacks is very low. 1083 An amplification attack to the constrained network may be triggered 1084 by a multicast request generated by a single HTTP request mapped to a 1085 CoAP multicast resource, as considered in Section TBD of [RFC7252]. 1087 The impact of this amplification technique is higher than an 1088 amplification attack carried out by a malicious constrained device 1089 (e.g. ICMPv6 flooding, like Packet Too Big, or Parameter Problem on 1090 a multicast destination [RFC4732]), since it does not require direct 1091 access to the constrained network. 1093 The feasibility of this attack, disruptive in terms of CoAP server 1094 availability, can be limited by access controlling the exposed HTTP 1095 multicast resource, so that only known/authorized users access such 1096 URIs. 1098 8.2. Handling Secured Exchanges 1100 It is possible that the request from the client to the HC Proxy is 1101 sent over a secured connection. However, there may or may not exist 1102 a secure connection mapping to the other protocol. For example, a 1103 secure distribution method for multicast traffic is complex and MAY 1104 not be implemented (see [I-D.ietf-core-groupcomm]). 1106 By default, a HC Proxy SHOULD reject any secured client request if 1107 there is no configured security policy mapping. This recommendation 1108 MAY be relaxed in case the destination network is believed to be 1109 secured by other, complementary, means. E.g.: assumed that CoAP 1110 nodes are isolated behind a firewall (e.g. as the SS HC proxy 1111 deployment shown in Figure 1), the HC Proxy may be configured to 1112 translate the incoming HTTPS request using plain CoAP (i.e. NoSec 1113 mode.) 1115 The HC URI mapping MUST NOT map to HTTP (see Section 5) a CoAP 1116 resource intended to be accessed only using HTTPS. 1118 A secured connection that is terminated at the HC Proxy, i.e. the 1119 proxy decrypts secured data locally, raises an ambiguity about the 1120 cacheability of the requested resource. The HC Proxy SHOULD NOT 1121 cache any secured content to avoid any leak of secured information. 1122 However in some specific scenario, a security/efficiency trade-off 1123 could motivate caching secured information; in that case the caching 1124 behavior MAY be tuned to some extent on a per-resource basis. 1126 8.3. URI Mapping 1128 The following risks related to the URI mapping described in Section 5 1129 have been identified: 1131 DoS attack on the internal network. 1132 Default deny any Target CoAP URI whose authority is (or maps to) a 1133 multicast address. Then explicitly whitelist multicast resources 1134 that are allowed to be de-referenced. 1136 Leaking information on the internal network resources and topology. 1137 Default deny any Target CoAP URI (especially /.well-known/core is 1138 the resource to be protected), and then explicit whitelist 1139 resources that are allowed to be seen from outside. 1141 Reduced privacy due to the mechanics of the URI mapping. 1142 The internal CoAP Target resource is totally transparent from 1143 outside: an HC Proxy implementing a HTTPS-only interface makes the 1144 Target CoAP URI totally opaque to a passive attacker. 1146 9. Acknowledgements 1148 An initial version of the table found in Section 6.2 has been 1149 provided in revision -05 of [RFC7252]. Special thanks to Peter van 1150 der Stok for countless comments and discussions on this document, 1151 that contributed to its current structure and text. 1153 Thanks to Carsten Bormann, Zach Shelby, Michele Rossi, Nicola Bui, 1154 Michele Zorzi, Klaus Hartke, Cullen Jennings, Kepeng Li, Brian Frank, 1155 Peter Saint-Andre, Kerry Lynn, Linyi Tian, Dorothy Gellert, Francesco 1156 Corazza for helpful comments and discussions that have shaped the 1157 document. 1159 The research leading to these results has received funding from the 1160 European Community's Seventh Framework Programme [FP7/2007-2013] 1161 under grant agreement n. [251557]. 1163 10. References 1165 10.1. Normative References 1167 [I-D.ietf-core-block] 1168 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1169 draft-ietf-core-block-12 (work in progress), June 2013. 1171 [I-D.ietf-core-observe] 1172 Hartke, K., "Observing Resources in CoAP", draft-ietf- 1173 core-observe-14 (work in progress), June 2014. 1175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1176 Requirement Levels", BCP 14, RFC 2119, March 1997. 1178 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1179 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1180 3986, January 2005. 1182 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 1183 and D. Orchard, "URI Template", RFC 6570, March 2012. 1185 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1186 Format", RFC 6690, August 2012. 1188 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1189 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1190 2014. 1192 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1193 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1195 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1196 (HTTP/1.1): Authentication", RFC 7235, June 2014. 1198 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1199 Application Protocol (CoAP)", RFC 7252, June 2014. 1201 10.2. Informative References 1203 [I-D.ietf-core-groupcomm] 1204 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1205 draft-ietf-core-groupcomm-19 (work in progress), June 1206 2014. 1208 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1209 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1210 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1212 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 1213 Replication and Caching Taxonomy", RFC 3040, January 2001. 1215 [RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface 1216 (CGI) Version 1.1", RFC 3875, October 2004. 1218 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1219 Service Considerations", RFC 4732, December 2006. 1221 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1222 Representation (CBOR)", RFC 7049, October 2013. 1224 Appendix A. Change Log 1226 [Note to RFC Editor: Please remove this section before publication.] 1228 Changes from ietf-03 to ietf-04: 1230 o Expanded use case descriptions in Section 4; 1232 o Fixed/enhanced discovery examples in Section 5.4.1; 1234 o Addressed Ticket #365 (Add text on media-type conversion by HTTP- 1235 CoAP proxy) in new section 6.3.1 (Generalized media-type mapping) 1236 and new section 6.3.2 (Content translation); 1238 o Updated HTTPBis WG draft references to recently published RFC 1239 numbers. 1241 o Various editorial improvements. 1243 Changes from ietf-02 to ietf-03: 1245 o Closed Ticket #351 "Add security implications of proposed default 1246 HC URI mapping"; 1248 o Closed Ticket #363 "Remove CoAP scheme in default HTTP-CoAP URI 1249 mapping"; 1251 o Closed Ticket #364 "Add discovery of HTTP-CoAP mapping 1252 resource(s)". 1254 Changes from ietf-01 to ietf-02: 1256 o Selection of single default URI mapping proposal as proposed to WG 1257 mailing list 2013-10-09. 1259 Changes from ietf-00 to ietf-01: 1261 o Added URI mapping proposals to Section 4 as per the Email 1262 proposals to WG mailing list from Esko. 1264 Authors' Addresses 1266 Angelo P. Castellani 1267 University of Padova 1268 Via Gradenigo 6/B 1269 Padova 35131 1270 Italy 1272 Email: angelo@castellani.net 1274 Salvatore Loreto 1275 Ericsson 1276 Hirsalantie 11 1277 Jorvas 02420 1278 Finland 1280 Email: salvatore.loreto@ericsson.com 1282 Akbar Rahman 1283 InterDigital Communications, LLC 1284 1000 Sherbrooke Street West 1285 Montreal H3A 3G4 1286 Canada 1288 Phone: +1 514 585 0761 1289 Email: Akbar.Rahman@InterDigital.com 1291 Thomas Fossati 1292 Alcatel-Lucent 1293 3 Ely Road 1294 Milton, Cambridge CB24 6DD 1295 UK 1297 Email: thomas.fossati@alcatel-lucent.com 1299 Esko Dijk 1300 Philips Research 1301 High Tech Campus 34 1302 Eindhoven 5656 AE 1303 The Netherlands 1305 Email: esko.dijk@philips.com