idnits 2.17.1 draft-castellani-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 16 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 14 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1273 has weird spacing: '... client clie...' == Line 1825 has weird spacing: '... */xml appl...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: An HC v4/v6 proxy SHOULD always try to resolve the URI authority, and SHOULD prefer using the IPv6 resolution if available. The authority part of the URI is used internally by the HC proxy and SHOULD not be mapped to CoAP. -- The document date (April 27, 2012) is 4381 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 ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '251557' on line 1586 == Missing Reference: 'TBD' is mentioned on line 1800, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-core-block-04 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-07 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-00 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-02 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-18 == Outdated reference: A later version (-03) exists of draft-thomson-hybi-http-timeout-00 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-01) exists of draft-bormann-core-simple-server-discovery-00 == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-01 == Outdated reference: A later version (-18) exists of draft-snell-http-prefer-12 == Outdated reference: A later version (-05) exists of draft-vanderstok-core-bc-04 Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 3 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: October 29, 2012 Ericsson 6 A. Rahman 7 InterDigital Communications, LLC 8 T. Fossati 9 KoanLogic 10 E. Dijk 11 Philips Research 12 April 27, 2012 14 Best practices for HTTP-CoAP mapping implementation 15 draft-castellani-core-http-mapping-04 17 Abstract 19 This draft aims at being a base reference documentation for HTTP-CoAP 20 proxy implementors. It details deployment options, discusses 21 possible approaches for URI mapping, and provides useful 22 considerations related to protocol translation. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 29, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Cross-protocol resource identification using URIs . . . . . . 5 61 3.1. URI mapping . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1.1. Homogeneous mapping . . . . . . . . . . . . . . . . . 7 63 3.1.2. Embedded mapping . . . . . . . . . . . . . . . . . . . 7 64 4. HTTP-CoAP implementation . . . . . . . . . . . . . . . . . . . 8 65 4.1. Placement and deployment . . . . . . . . . . . . . . . . . 8 66 4.2. Basic mapping . . . . . . . . . . . . . . . . . . . . . . 10 67 4.2.1. Caching and congestion control . . . . . . . . . . . . 11 68 4.2.2. Cache Refresh via Observe . . . . . . . . . . . . . . 12 69 4.2.3. Use of CoAP blockwise transfer . . . . . . . . . . . . 13 70 4.2.4. Use case: HTTP/IPv4-CoAP/IPv6 proxy . . . . . . . . . 13 71 4.3. Multiple message exchanges mapping . . . . . . . . . . . . 15 72 4.3.1. Relevant features of existing standards . . . . . . . 15 73 4.3.2. Multicast mapping . . . . . . . . . . . . . . . . . . 16 74 4.3.3. Multicast responses caching . . . . . . . . . . . . . 19 75 4.3.4. Observe mapping . . . . . . . . . . . . . . . . . . . 20 76 5. CoAP-HTTP implementation . . . . . . . . . . . . . . . . . . . 28 77 5.1. Placement and Deployment . . . . . . . . . . . . . . . . . 29 78 5.2. Basic mapping . . . . . . . . . . . . . . . . . . . . . . 30 79 5.2.1. Payloads and Media Types . . . . . . . . . . . . . . . 30 80 5.2.2. Max-Age and ETag Options . . . . . . . . . . . . . . . 31 81 5.2.3. Use of CoAP blockwise transfer . . . . . . . . . . . . 31 82 5.2.4. HTTP Status Codes 1xx and 3xx . . . . . . . . . . . . 31 83 5.2.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 31 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 85 6.1. Traffic overflow . . . . . . . . . . . . . . . . . . . . . 34 86 6.2. Cross-protocol security policy mapping . . . . . . . . . . 34 87 6.3. Handling secured exchanges . . . . . . . . . . . . . . . . 35 88 6.4. Spoofing and Cache Poisoning . . . . . . . . . . . . . . . 35 89 6.5. Subscription . . . . . . . . . . . . . . . . . . . . . . . 36 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 92 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 93 8.2. Informative References . . . . . . . . . . . . . . . . . . 38 94 Appendix A. Internal Mapping Functions (from an implementer's 95 perspective) . . . . . . . . . . . . . . . . . . . . 39 96 A.1. URL Map Algorithm . . . . . . . . . . . . . . . . . . . . 39 97 A.2. Security Policy Map Algorithm . . . . . . . . . . . . . . 40 98 A.3. Content-Type Map Algorithm . . . . . . . . . . . . . . . . 41 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 101 1. Introduction 103 RESTful protocols, such as HTTP [RFC2616] and CoAP 104 [I-D.ietf-core-coap], can interoperate through an intermediary proxy 105 which performs cross-protocol mapping. 107 A reference about the mapping process is provided in Section 8 of 108 [I-D.ietf-core-coap]. However, depending on the involved 109 application, deployment scenario, or network topology, such mapping 110 could be realized using a wide range of intermediaries. 112 Moreover, the process of implementing such a proxy could be complex, 113 and details regarding its internal procedures and design choices 114 deserve further discussion, which is provided in this document. 116 This draft is organized as follows: 118 o Section 2 describes terminology to identify different mapping 119 approaches and the related proxy deployments; 121 o Section 3 discusses impact of the mapping on URI and describes 122 notable options; 124 o Section 4 and Section 5 respectively analyze the mapping from HTTP 125 to CoAP and viceversa; 127 o Section 6 discusses possible security impact related to the 128 mapping. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 2. Terminology 136 A device providing cross-protocol HTTP-CoAP mapping is called an 137 HTTP-CoAP cross-protocol proxy (HC proxy). 139 At least two different kinds of HC proxies exist: 141 o One-way cross-protocol proxy (1-way proxy): This proxy translates 142 from a client of a protocol to a server of another protocol but 143 not vice-versa. 145 o Two-way (or bidirectional) cross-protocol proxy (2-way proxy): 146 This proxy translates from a client of both protocols to a server 147 supporting one protocol. 149 1-way and 2-way HC proxies are realized using the following general 150 types of proxies: 152 Forward proxy (F): Is a proxy known by the client (either CoAP or 153 HTTP) used to access a specific cross-protocol server 154 (respectively HTTP or CoAP). Main feature: server(s) do not 155 require to be known in advance by the proxy (ZSC: Zero Server 156 Configuration). 158 Reverse proxy (R): Is a proxy known by the client to be the server, 159 however for a subset of resources it works as a proxy, by knowing 160 the real server(s) serving each resource. When a cross-protocol 161 resource is accessed by a client, the request will be silently 162 forwarded by the reverse proxy to the real server (running a 163 different protocol). If a response is received by the reverse 164 proxy, it will be mapped, if possible, to the original protocol 165 and sent back to the client. Main feature: client(s) do not 166 require to know in advance the proxy (ZCC: Zero Client 167 Configuration). 169 Interception proxy (I): This proxy [RFC3040] can intercept any 170 origin protocol request (HTTP or CoAP) and map it to the 171 destination protocol, without any kind of knowledge about the 172 client or server involved in the exchange. Main feature: 173 client(s) and server(s) do not require to know or be known in 174 advance by the proxy (ZCC and ZSC). 176 A server-side (SS) proxy is placed in the same network domain of the 177 server; Conversely a client-side (CS) is in the same network domain 178 of the client. Differently from these two cases, the proxy is said 179 to be External (E). 181 3. Cross-protocol resource identification using URIs 183 A Uniform Resource Identifier (URI) provides a simple and extensible 184 means for identifying a resource. It enables uniform identification 185 of resources via a separately defined extensible set of naming 186 schemes [RFC3986]. 188 URIs are formed of at least three components: scheme, authority and 189 path. The scheme is the first part of the URI, and it often 190 corresponds to the protocol used to access the resource. However, as 191 noted in Section 1.2.2 of [RFC3986] the scheme does not imply that a 192 particular protocol is used to access the resource. 194 Clients using URIs to identify target resources (e.g. HTTP web 195 browsers) may support only a limited set of schemes (i.e. 'http', 196 'https'). If such clients need to interoperate with resources 197 identified by an unsupported scheme (e.g. 'coap'), the existence of a 198 URI using a scheme supported by the client is required for 199 interoperability. 201 Both CoAP and HTTP implement the REST paradigm, so, in principle, the 202 same resource can be made available in each protocol if protocol 203 translation is applied. 205 In general two different procedures can be used by a client to access 206 cross-protocol resources: 208 Protocol-aware access: Happens when a client knows the other 209 protocol domain and accesses the cross-protocol resource using its 210 URI by using an HC proxy. Example: An HTTP client accesses a CoAP 211 resource by addressing it using the 'coap' scheme inside the HTTP 212 request (actual protocol translation is provided by the proxy). 213 Both HTTP and CoAP allow using different schemes in requests to 214 proxies: (i) see Section 4.1.2 of [I-D.ietf-httpbis-p1-messaging], 215 and (ii) Section 5.10.3 of [I-D.ietf-core-coap]. 217 Protocol-agnostic access: The client accesses the cross-protocol 218 resource using an URI with a scheme supported by the client (e.g. 219 uses 'http' scheme to access a CoAP resource), URI and protocol 220 translation is provided by a cross-protocol proxy. In order to 221 use this method a URI identifying an equivalent resource MUST 222 exist, and SHOULD be provided by the cross-protocol proxy. 224 URI mapping is NOT required when using protocol-aware access, the 225 following section is focused on URI mapping techniques for protocol- 226 agnostic access. 228 3.1. URI mapping 230 When accessing cross-protocol resources in a protocol-agnostic way, 231 clients MUST use an URI with a scheme supported by the client. 233 Since determination of equivalence of URIs (e.g. whether or not they 234 identify the same resource) is based on lexicographic comparison, URI 235 domains using different schemes are fully distinct: resources 236 identified by the same authority and path tuple change when switching 237 the scheme. 239 Example: Assume that the following resource exists - 240 "coap://node.coap.something.net/foo". The resource identified by 241 "http://node.coap.something.net/foo" may not exist or be non- 242 equivalent to the one identified by the 'coap' scheme. 244 If a cross-protocol URI exists providing an equivalent representation 245 of the native protocol resource, it can be provided by a different 246 URI (in terms of authority and path). The mapping of an URI between 247 HTTP and CoAP is said HC URI mapping. 249 Example: The HC URI mapping to HTTP of the CoAP resource identified 250 by "coap://node.coap.something.net/foo" is 251 "http://node.something.net/foobar". 253 The process of providing the HC URI mapping could be complex, since a 254 proper mechanism to statically or dynamically (discover) map the 255 resource HC URI mapping is required. 257 Two static HC URI mappings are discussed in the following 258 subsections. 260 3.1.1. Homogeneous mapping 262 The URI mapping between CoAP and HTTP is called homogeneous, if the 263 same resource is identified by URIs with different schemes. 265 Example: The CoAP resource "//node.coap.something.net/foo" identified 266 either by the URI "coap://node.coap.something.net/foo", and or by the 267 URI "http://node.coap.something.net/foo" is the same. When the 268 resource is accessed using HTTP, the mapping from HTTP to CoAP is 269 performed by an HC proxy 271 When homogeneous HC URI mapping is available, HC-I proxies are easily 272 implementable. 274 3.1.2. Embedded mapping 276 When the HC URI mapping of the resource embeds inside it the 277 authority and path part of the native URI, then the mapping is said 278 to be embedded. 280 Example: The CoAP resource "coap://node.coap.something.net/foo" can 281 be accessed at 282 "http://hc-proxy.something.net/coap/node.coap.something.net/foo". 284 This mapping technique can be used to reduce the mapping complexity 285 in an HC reverse proxy. 287 3.1.2.1. HTML5 scheme handler registration 289 The draft HTML5 standard offers a mechanism that allows an HTTP user 290 agent to register a custom scheme handler through an HTML5 web page. 291 This feature permits to an HC proxy to be registered as "handler" for 292 URIs with the 'web+coap' or 'web+coaps' schemes using an HTML5 web 293 page which embeds the custom scheme handler registration call 294 registerProtocolHandler() described in Section 6.5.1.2 of 295 [W3C.HTML5]. 297 Example: the HTML5 homepage of a HC proxy at h2c.example.org could 298 include the method call: 300 registerProtocolHandler('web+coap', 'proxy?url=%s', 'example HC proxy') 302 This registration call will prompt the HTTP user agent to ask for the 303 user's permission to register the HC proxy as a handler for all 'web+ 304 coap' URIs. If the user accepts, whenever a 'web+coap' link is 305 requested, the request will be fulfilled through the HC proxy: URI 306 "web+coap://foo.org/a" will be transformed into URI 307 "http://h2c.example.org/proxy?url=web+coap://foo.org/a". 309 4. HTTP-CoAP implementation 311 4.1. Placement and deployment 313 In typical scenarios the HC proxy is expected to be server-side (SS), 314 in particular deployed at the edge of the constrained network. 316 The arguments supporting SS placement are the following: 318 TCP/UDP: Translation between HTTP and CoAP requires also a TCP to 319 UDP mapping; UDP performance over the unconstrained Internet may 320 not be adequate. In order to minimize the number of required 321 retransmissions and overall reliability, TCP/UDP conversion SHOULD 322 be performed at a SS placed proxy. 324 Caching: Efficient caching requires that all the CoAP traffic is 325 intercepted by the same proxy, thus an SS placement, collecting 326 all the traffic, is strategical for this need. 328 Multicast: To support using local-multicast functionalities 329 available in the constrained network, the HC proxy MAY require a 330 network interface directly attached to the constrained network. 332 +------+ 333 | | 334 | DNS | 335 | | 336 +------+ 337 -------------------- 338 / \ 339 / /-----\ /-----\ \ 340 / CoAP CoAP \ 341 / server server \ 342 || \-----/ \-----/ || 343 +----------+ || 344 | HTTP/CoAP| /-----\ || 345 | Proxy | CoAP || 346 |(HC Proxy)| server || 347 +------+ +----------+ \-----/ || 348 |HTTP | || /-----\ || 349 |Client| || CoAP || 350 +------+ \ server / 351 \ \-----/ / 352 \ /-----\ / 353 \ CoAP / 354 \ server / 355 \ \-----/ / 356 ---------------- 358 Figure 1: Server-side HC proxy deployment scenario 360 Other important aspects involved in the selection of which type of 361 proxy deployment, whose choice impacts its placement too, are the 362 following: 364 Client/Proxy/Network configuration overhead: Forward proxies require 365 either static configuration or discovery support in the client. 366 Reverse proxies require either static configuration, server 367 discovery or embedded URI mapping in the proxy. Interception 368 proxies require minimal deployment effor (i.e. web traffic routing 369 towards the proxy). 371 Scalability/Availability: Both aspects are typically addressed using 372 redundancy. CS deployments, due to the limited catchment area and 373 administrative-wide domain of operation, have looser requirements 374 on this. SS deployments, in dense/popular/critical environments, 375 have stricter requirements and MAY need to be replicated. 376 Stateful proxies (e.g. reverse) may be complex to replicate. 378 Discussion about security impacts of different deployments is covered 379 in Section 6. 381 Table 1 shows some interesting HC proxy deployment scenarios, and 382 notes the advantages related to each scenario. 384 +--------------------------+------+------+------+ 385 | Feature | F CS | R SS | I SS | 386 +--------------------------+------+------+------+ 387 | TCP/UDP | - | + | + | 388 | Multicast | - | + | + | 389 | Caching | - | + | + | 390 | Scalability/Availability | + | +/- | + | 391 | Configuration | - | - | + | 392 +--------------------------+------+------+------+ 394 Table 1: Interesting HC proxy deployments 396 Guidelines proposed in the previous paragraphs have been used to fill 397 out the above table. In the first three rows, it can be seen that SS 398 deployment is preferred versus CS. Scalability/Availability issues 399 can be generally handled, but some complexity may be involved in 400 reverse proxies scenarios. Configuration overhead could be 401 simplified when interception proxies deployments are feasible. 403 When support for legacy HTTP clients is required, it may be 404 preferable using configuration/discovery free deployments. Discovery 405 procedures for client or proxy auto-configuration are still under 406 active-discussion: see [I-D.vanderstok-core-bc], 407 [I-D.bormann-core-simple-server-discovery] or 408 [I-D.shelby-core-resource-directory]. Static configuration of 409 multiple forward proxies is typically not feasible in existing HTTP 410 clients. 412 4.2. Basic mapping 414 The mapping of HTTP requests to CoAP and of the response back to HTTP 415 is defined in Section 8.2 of [I-D.ietf-core-coap]. 417 The mapping of a CoAP response code to HTTP is not straightforward, 418 this mapping MUST be operated accordingly to Table 4 of 419 [I-D.ietf-core-coap]. 421 No temporal upper bound is defined for a CoAP server to provide the 422 response, thus for long delays the HTTP client or any other proxy in 423 between MAY timeout. Further discussion is available in Section 424 7.1.4 of [I-D.ietf-httpbis-p1-messaging]. 426 The HC proxy MUST define an internal timeout for each pending CoAP 427 request, because the CoAP server may silently die before completing 428 the request. 430 Even if the DNS protocol may not be used inside the constrained 431 network, having valid DNS entries for constrained hosts, where 432 possible, MAY help HTTP clients to access the resources offered by 433 them. 435 An example of the usefulness of such entries is described in 436 Section 4.2.4. 438 HTTP connection pipelining (section 7.1.2.2 of 439 [I-D.ietf-httpbis-p1-messaging]) is transparent to the CoAP network: 440 the HC proxy will sequentially serve the pipelined requests by 441 issuing different CoAP requests. 443 4.2.1. Caching and congestion control 445 The HC proxy SHOULD limit the number of requests to CoAP servers by 446 responding, where applicable, with a cached representation of the 447 resource. 449 Duplicate idempotent pending requests to the same resource SHOULD in 450 general be avoided, by duplexing the response to the relevant hosts 451 without duplicating the request. 453 If the HTTP client times out and drops the HTTP session to the proxy 454 (closing the TCP connection), the HC proxy SHOULD wait for the 455 response and cache it if possible. Further idempotent requests to 456 the same resource can use the result present in cache, or, if a 457 response has still to come, requests will wait on the open CoAP 458 session. 460 Resources experiencing a high access rate coupled with high 461 volatility MAY be observed [I-D.ietf-core-observe] by the HC proxy to 462 keep their cached representation fresh while minimizing the number of 463 needed messages. See Section 4.2.2 for a heuristics that enables the 464 HC proxy to decide whether observing is a more convenient strategy 465 than ordinary refreshing via Max-Age/ETag-based mechanisms. 467 Specific deployments may show highly congested servers/resources -- 468 e.g. multicast resources (see Section 4.3.2), popular servers, etc. 469 A careful analysis is required to pick the correct caching policy 470 involving these resources, also taking into consideration the 471 security implications that may impact these targets specifically, and 472 the constrained network in general. 474 To this end when traffic reduction obtained by the caching mechanism 475 is not adequate, the HC proxy could apply stricter policing by 476 limiting the amount of aggregate traffic to the constrained network. 477 In particular, the HC proxy SHOULD pose a rigid upper limit to the 478 number of concurrent CoAP request pending on the same constrained 479 network; further request MAY either be queued or dropped. In order 480 to efficiently apply this congestion control, the HC proxy SHOULD be 481 SS placed. 483 Further discussion on congestion control can be found in 484 [I-D.eggert-core-congestion-control]. 486 4.2.2. Cache Refresh via Observe 488 There are cases where using CoAP observe protocol to handle proxy 489 cache refresh may be preferable to the validation mechanism based on 490 ETag's defined in section 5.6.2 of [I-D.ietf-core-coap]. Such 491 scenarios include, but are not limited to, sleeping nodes -- with 492 possibly high variance in requests' distribution -- which would 493 greatly benefit from a server driven cache update mechanism. Ideal 494 candidates would also be the crowded or very low throughput networks, 495 where reduction of the total number of exchanged messages is an 496 important requirement. 498 This subsection aims at providing a practical evaluation method to 499 decide whether the refresh of a cached resource R is more efficiently 500 handled via ETag validation or by establishing an observation on R. 502 Let T_R be the mean time between two client requests to resource R, 503 let F_R be the freshness lifetime of R representation, and let M_R be 504 the total number of messages exchanged towards resource R. If we 505 assume that the initial cost for establishing the observation is 506 negligible, an observation on R reduces M_R iff T_R < 2*F_R with 507 respect to using ETag validation, that is iff the mean arrival time 508 of requests for resource R is greater than half the refresh rate of 509 R. 511 When using observations M_R is always upper bounded by 2*F_R: in the 512 constrained network no more than 2*F_R messages will be generated 513 towards resource R. 515 Proof: Let T be the evaluated interval of time, let M_Ro be the total 516 number of messages exchanged towards resource R using observation, 517 and let M_Re be the total number of messages exchanged towards 518 resource R using ETag validation. The following equations hold M_Re 519 = T*2/T_R, M_Ro = T/F_R. M_Ro < M_Re iff 1/F_R < 2/T_R, that is T_R < 520 2*F_R. The amount of messages saved using observation is T*(2*F_R- 521 T_R)/(T_R*F_R). 523 Example: assume that F_R is one second and T_R is 1.5 seconds. Since 524 1.5 is lower than 2*1, an observation on R reduces M_R. In a single 525 day of usage, 28800 messages will be saved if the HC proxy 526 establishes an observation on R. The single message cost required to 527 establish this observation is negligible. 529 4.2.3. Use of CoAP blockwise transfer 531 An HC proxy SHOULD support CoAP blockwise transfers 532 [I-D.ietf-core-block] to allow transport of large CoAP payloads while 533 avoiding link-layer fragmentation in LLNs, and to cope with small 534 datagram buffers in CoAP end-points as described in 535 [I-D.ietf-core-coap]. An HC proxy SHOULD attempt to retry a CoAP PUT 536 or POST request with a payload using blockwise transfer if the 537 destination CoAP server responded with 4.13 (Request Entity Too 538 Large) to the original request. An HC proxy SHOULD attempt to use 539 blockwise transfer when sending a CoAP PUT or POST request message 540 that is larger than BLOCKWISE_THRESHOLD. The value of 541 BLOCKWISE_THRESHOLD is implementation-specific, for example it may 542 set by an administrator, preset to a known or typical UDP datagram 543 buffer size for CoAP end-points, to N times the size of a link-layer 544 frame where e.g. N=5, preset to a known IP MTU value, or set to a 545 known Path MTU value. 547 For improved latency an HC proxy MAY initiate a blockwise CoAP 548 request triggered by an incoming HTTP request even when the HTTP 549 request message has not yet been fully received, but enough data has 550 been received to send one or more data blocks to a CoAP server 551 already. 553 4.2.4. Use case: HTTP/IPv4-CoAP/IPv6 proxy 555 This section covers the expected common use case regarding an HTTP/ 556 IPv4 client accessing a CoAP/IPv6 resource. 558 While HTTP and IPv4 are today widely adopted communication protocols 559 in the Internet, a pervasive deployment of constrained nodes 560 exploiting the IPv6 address space is expected: enabling direct 561 interoperability of such technologies is a valuable goal. 563 An HC proxy supporting IPv4/IPv6 mapping is said to be a v4/v6 proxy. 565 An HC v4/v6 proxy SHOULD always try to resolve the URI authority, and 566 SHOULD prefer using the IPv6 resolution if available. The authority 567 part of the URI is used internally by the HC proxy and SHOULD not be 568 mapped to CoAP. 570 Figure 2 shows an HTTP client on IPv4 (C) accessing a CoAP server on 571 IPv6 (S) through an HC proxy on IPv4/IPv6 (P). The DNS has an A 572 record for "node.coap.something.net" resolving to the IPv4 address of 573 the HC proxy, and an AAAA record with the IPv6 address of the CoAP 574 server. 576 C P S 577 | | | 578 | | | Source: IPv4 of C 579 | | | Destination: IPv4 of P 580 +---->| | GET /foo HTTP/1.1 581 | | | Host: node.coap.something.net 582 | | | ..other HTTP headers .. 583 | | | 584 | | | Source: IPv6 of P 585 | | | Destination: IPv6 of S 586 | +---->| CON GET 587 | | | URI-Path: foo 588 | | | 589 | | | Source: IPv6 of S 590 | | | Destination: IPv6 of P 591 | |<----+ ACK 592 | | | 593 | | | ... Time passes ... 594 | | | 595 | | | Source: IPv6 of S 596 | | | Destination: IPv6 of P 597 | |<----+ CON 2.00 598 | | | "bar" 599 | | | 600 | | | Source: IPv6 of P 601 | | | Destination: IPv6 of S 602 | +---->| ACK 603 | | | 604 | | | Source: IPv4 of P 605 | | | Destination: IPv4 of C 606 |<----+ | HTTP/1.1 200 OK 607 | | | .. other HTTP headers .. 608 | | | 609 | | | bar 610 | | | 612 Figure 2: HTTP/IPv4 to CoAP/IPv6 mapping 614 The proposed example shows the HC proxy operating also the mapping 615 between IPv4 to IPv6 using the authority information available in any 616 HTTP 1.1 request. This way, IPv6 connectivity is not required at the 617 HTTP client when accessing a CoAP server over IPv6 only, which is a 618 typical expected use case. 620 When P is an interception HC proxy, the CoAP request SHOULD have the 621 IPv6 address of C as source (IPv4 can always be mapped into IPv6). 623 The described solution takes into account only the HTTP/IPv4 clients 624 accessing CoAP/IPv6 servers; this solution does not provide a full 625 fledged mapping from HTTP to CoAP. 627 In order to obtain a working deployment for HTTP/IPv6 clients, a 628 different HC proxy access method may be required, or Internet AAAA 629 records should not point to the node anymore (the HC proxy should use 630 a different DNS database pointing to the node). 632 When an HC interception proxy deployment is used this solution is 633 fully working even with HTTP/IPv6 clients. 635 4.3. Multiple message exchanges mapping 637 This section discusses the mapping of the multicast and observe 638 features of CoAP, which have no corresponding primitive in HTTP, and 639 as such are not immediately translatable. 641 The mapping, which must be considered in both the arrow directions 642 (H->C, C->H) may involve multi-part responses, as in the multicast 643 use case, asynchronous delivery through HTTP bidirectional 644 techniques, and HTTP Web Linking in order to reduce the semantics 645 lost in the translation. 647 4.3.1. Relevant features of existing standards 649 Various features provided by existing standards are useful to 650 efficiently represent sessions involving multiple messages. 652 4.3.1.1. Multipart messages 654 In particular, the "multipart/*" media type, defined in Section 5.1 655 of [RFC2046], is a suitable solution to deliver multiple CoAP 656 responses within a single HTTP payload. Each part of a multipart 657 entity SHOULD be represented using "message/http" media type 658 containing the full mapping of a single CoAP response as previously 659 described. 661 4.3.1.2. Immediate message delivery 663 An HC proxy may prefer to transfer each CoAP response immediately 664 after its reception. This is possible thanks to the HTTP Transfer- 665 Encoding "chunked", that enables transferring single responses 666 without any further delay. 668 A detailed discussion on the use of chunked Transfer-Encoding to 669 stream data over HTTP can be found in [RFC6202]. Large delays 670 between chunks can lead the HTTP session to timeout, more details on 671 this issue can be found in [I-D.thomson-hybi-http-timeout]. 673 An HC proxy MAY prefer (e.g. to avoid buffering) to transfer each 674 response related to a multicast request as soon as it comes in from 675 the server. One possible way to achieve this result is using the 676 "chunked" Transfer-Encoding in the HTTP response, to push individual 677 responses until some trigger is fired (timeout, max number of 678 messages, etc.). 680 An example showing immediate delivery of CoAP responses using HTTP 681 chunks will be provided in Section 4.3.4, while describing its 682 application to an observe session. 684 4.3.1.3. Detailing source information 686 Under some circumstances, responses may come from different sources 687 (i.e. responses to a multicast request); in this case details about 688 the actual source of each CoAP response MAY be provided to the 689 client. Source information can be represented using HTTP Web Linking 690 as defined in [RFC5988], by adding the actual source URI into each 691 response using Link option with "via" relation type. 693 4.3.2. Multicast mapping 695 In order to establish a multicast communication such a feature should 696 be offered either by the network (i.e. IP multicast, link-layer 697 multicast, etc.) or by a gateway (i.e. the HC proxy). Rationale on 698 the methods available to obtain such a feature is out-of-scope of 699 this document, and extensive discussion of group communication 700 techniques is available in [I-D.ietf-core-groupcomm]. 702 Additional considerations related to handling multicast requests 703 mapping are detailed in the following sections. 705 4.3.2.1. URI identification and mapping 707 In order to successfully handle a multicast request, the HC proxy 708 MUST successfully perform the following tasks on the URI: 710 Identification: The HC proxy MUST understand whether the requested 711 URI identifies a group of nodes. 713 Mapping: The HC proxy MUST know how to distribute the multicast 714 request to involved servers; this process is specific of the group 715 communication technology used. 717 When using IPv6 multicast paired with DNS, the mapping to IPv6 718 multicast is simply done using DNS resolution. If the group 719 management is performed at the proxy, the URI or part of it (i.e. the 720 authority) can be mapped using some static or dynamic table available 721 at the HC proxy. In Section 3.5 of [I-D.ietf-core-groupcomm] 722 discusses a method to build and maintain a local table of multicast 723 authorities. 725 4.3.2.2. Request handling 727 When the HC proxy receives a request to a URI that has been 728 successfully identified and mapped to a group of nodes, it SHOULD 729 start a multicast proxying operation, if supported by the proxy. 731 Multicast request handling consists of the following steps: 733 Multicast TX: The HC proxy sends out the request on the CoAP side by 734 using the methods offered by the specific group communication 735 technology used in the constrained network; 737 Collecting RXs: The HC proxy collects every response related to the 738 request; 740 Timeout: The HC proxy has to pay special attention in multicast 741 timing, detailed discussion about timing depends upon the 742 particular group communication technology used; 744 Distributing RXs to the client: The HC proxy can distribute the 745 responses in two different ways: batch delivering them at the end 746 of the process or on timeout, or immediately delivering them as 747 they are available. Batch requires more caching and introduces 748 delays but may lead to lower TCP overhead and simpler processing. 749 Immediate delivery is the converse. A trade-off solution of 750 partial batch delivery may also be feasible and efficient in some 751 circumstances. 753 4.3.2.3. Examples 755 Figure 3 shows an HTTP client (C) requesting the resource "/foo" to a 756 group of CoAP servers (S1/S2/S3) through an HC proxy (P) which uses 757 IP multicast to send the corresponding CoAP request. 759 C P S1 S2 S3 760 | | | | | 761 +---->| | | | GET /foo HTTP/1.1 762 | | | | | Host: group-of-nodes.coap.something.net 763 | | | | | .. other HTTP headers .. 764 | | | | | 765 | +---->|---->|---->| NON GET 766 | | | | | URI-Path: foo 767 | | | | | 768 | |<----------+ | NON 2.00 769 | | | | | "S2" 770 | | | | | 771 | | X---------------+ NON 2.00 772 | | | | | "S3" 773 | | | | | 774 | |<----+ | | NON 2.00 775 | | | | | "S1" 776 | | | | | 777 | | | | | ... Timeout ... 778 | | | | | 779 |<----+ | | | HTTP/1.1 200 OK 780 | | | | | Content-Type: multipart/mixed; boundary="response" 781 | | | | | .. other HTTP headers .. 782 | | | | | 783 | | | | | --response 784 | | | | | Content-Type: message/http 785 | | | | | 786 | | | | | HTTP/1.1 200 OK 787 | | | | | Link: ; rel=via 788 | | | | | 789 | | | | | S2 790 | | | | | 791 | | | | | --response 792 | | | | | Content-Type: message/http 793 | | | | | 794 | | | | | HTTP/1.1 200 OK 795 | | | | | Link: ; rel=via 796 | | | | | 797 | | | | | S1 798 | | | | | 799 | | | | | --response-- 800 | | | | | 802 Figure 3: Unicast HTTP to multicast CoAP mapping 804 The example proposed in the above diagram does not make any 805 assumption on which underlying group communication technology is 806 available in the constrained network. Some detailed discussion is 807 provided about it along the following lines. 809 C makes a GET request to group-of-nodes.coap.something.net. This 810 domain name MAY either resolve to the address of P, or to the IPv6 811 multicast address of the nodes (if IP multicast is supported and P is 812 an interception proxy), or the proxy P is specifically known by the 813 client that sends this request to it. 815 To successfully start multicast proxying operation, the HC proxy MUST 816 know that the destination URI involves a group of CoAP servers, e.g. 817 the authority group-of-nodes.coap.something.net is known to identify 818 a group of nodes either by using an internal lookup table, using DNS 819 paired with IPv6 multicast, or by using some other special technique. 821 A specific implementation option is proposed to further explain the 822 proposed example. Assume that DNS is configured such that all 823 subdomain queries to coap.something.net, such as group-of- 824 nodes.coap.something.net, resolve to the address of P. P performs the 825 HC URI mapping by removing the 'coap' subdomain from the authority 826 and by switching the scheme from 'http' to 'coap' (result: 827 "coap://group-of-node.something.net/foo"); "group-of- 828 nodes.something.net" is resolved to an IPv6 multicast address to 829 which S1, S2 and S3 belong. The proxy handles this request as 830 multicast and sends the request "GET /foo" to the multicast group . 832 4.3.3. Multicast responses caching 834 We call perfect caching when the proxy uses only the cached 835 representations to provide a response to the HTTP client. In the 836 case of a multicast CoAP request, perfect caching is not adequate. 837 This section updates the general caching guidelines of Section 4.2.1 838 with specific guidelines for the multicast use case. 840 Due to the inherent unreliable nature of the NON messages involved 841 and since nodes may have dynamic membership in multicast groups, 842 responding only with previously cached responses without issuing a 843 new multicast request is not recommended. This perfect caching 844 behaviour leads to miss responses of nodes that later joined the 845 multicast group, and/or to repeately serve partial representations 846 due to message losses. Therefore a multicast CoAP request SHOULD be 847 sent by a HC proxy for each incoming request addressed to a multicast 848 group. 850 Caching of multicast responses is still a valuable goal to pursue 851 reduce network congestion, battery consumption and response latency. 852 Some considerations to be performed when adopting a multicast caching 853 behaviour are outlined in the following paragraph. 855 Caching of multicast GET responses MAY be implemented by adopting 856 some technique that takes into account either knowledge about dynamic 857 characteristics of group membership (occurrence or frequency of group 858 changes) or even better its full knowledge (list of nodes currently 859 part of the group). 861 When using a technique exploiting this knowledge, valid cached 862 responses SHOULD be served from cache. 864 4.3.4. Observe mapping 866 By design, and certainly not without a good rationale, HTTP lacks a 867 publish-subscriber facility. This implies that the mapping of the 868 CoAP observe semantics has to be created ad hoc, perhaps by making 869 use of one of the well-known HTTP techniques currently employed to 870 establish an HTTP bidirectional connection with the target resource - 871 as documented in [RFC6202]. 873 In the following sections we will describe some of the approaches 874 that can be used to identify an observable resource and to create the 875 communication bridging needed to set up an end to end HTTP-CoAP 876 observation. 878 4.3.4.1. Identification 880 In order to appropriately process an observe request, the HC proxy 881 needs to know whether a given request is intended to establish an 882 observation on the target resource, instead of triggering a regular 883 request-response exchange. 885 At least two different approaches to identify such special requests 886 exist, as discussed below. 888 4.3.4.1.1. Observable URI mapping 890 An URI is said to be observable whenever every request to it 891 implicitly requires the establishment of an HTTP bidirectional 892 connection to the resource. 894 Such subscription to the resource is always paired, if possible, to a 895 CoAP observe session to the actual resource being observed. In 896 general, multiple connections that are active with a single 897 observable resource at the same time, are multiplexed to the single 898 observe session opened by the intermediary. Its notifications are 899 then de-multiplexed by the HC proxy to every HTTP subscriber. 901 An intermediary MAY pair a couple of distinct HTTP URIs to a single 902 CoAP observable resource: one providing the usual request-response 903 mediated access to the resource, and the other that always triggers a 904 CoAP observe session. 906 4.3.4.1.1.1. Discovery 908 As shown in Figure 4, in order to know whether an URI is observable, 909 an HTTP UA MAY do a preflight request to the target resource using 910 the HTTP OPTIONS method (see section 6.2 of 911 [I-D.ietf-httpbis-p2-semantics]) to discover the communication 912 options available for that resource. 914 If the resource supports observation, the proxy adds a Link Header 915 [RFC5988] with the "obs" attribute as link-param (see Section 7 of 916 [I-D.ietf-core-observe]). 918 C P S 919 | | | OPTIONS /kitchen/temp HTTP/1.1 920 +------>| | Host: node.coap.something.net 921 | | | 922 | +------>| CON GET 923 | | | Uri-Path: /.well-known/core?anchor=/kitchen/temp 924 | | | 925 | |<------+ ACK 2.05 926 | | | Payload: ;obs 927 | | | 928 |<------+ | HTTP/1.1 200 OK 929 | | | Link: ; obs; type="application/atom+xml" 930 | | | Allow: GET, OPTIONS 932 Figure 4: Discover observability with HTTP OPTIONS 934 4.3.4.1.2. Differentiation using HTTP Header 936 Discerning an observation request through in-protocol means, e.g. via 937 the presence and values of some HTTP metadata, avoids introducing 938 static "observable" URIs in the HC proxy namespace. Though ideally 939 the former should be preferred, there seems to be no standard way to 940 use one of the established HTTP headers to convey the observe 941 semantics. 943 Standardizing such methods is out-of-scope of this document, so we 944 just point out some possible approaches that in the future may be 945 used to differentiate observation requests from regular requests. 947 4.3.4.1.2.1. Expect Header 949 The first method involves the use of the Expect header as defined in 950 Section 9.3 of [I-D.ietf-httpbis-p2-semantics]. Whenever an HC proxy 951 receives a request with a "206-partial-content" expectation, the 952 proxy MUST fulfill this expectation by pairing this request to either 953 a new or existing observe session to the resource. 955 If the proxy is unable to observe the resource, or if the observation 956 establishment fails, the proxy MUST reply to the client with "417 957 Expectation Failed" status code. 959 Given that the Expect header is processed hop-by-hop, this method 960 will fail immediately in case a proxy not supporting this expectation 961 is traversed. For this reason, at present, the said approach can't 962 be used in the public Internet. 964 4.3.4.1.2.2. Prefer Header 966 A second, very similar, approach involves the use of the Prefer 967 header, defined in [I-D.snell-http-prefer]. The HTTP user agent 968 expresses the preference to establish an observation with the target 969 resource by including a "streaming" preference to request an HTTP 970 Streaming session, or a "long-polling" preference to signal to the 971 proxy its intended polling behaviour (see [RFC6202]). 973 A compliant HC proxy will try to fulfill the preference, and manifest 974 observation establishment success by responding with a status code of 975 "206 Partial Content". The observation request fails, falling back 976 to a single response, whenever the status code is different from 206. 978 This approach will never fail immediately, differently from the 979 previous one, even across a chain of unaware proxies; however, as 980 documented in [RFC6202], caching intermediaries may interfere, delay 981 or block the HTTP bidirectional connection, making this approach 982 unacceptable when no weak consistency of the resource can be 983 tolerated by the requesting UA. 985 4.3.4.2. Notification(s) mapping 987 Multiplexing notifications using a single HTTP bidirectional session 988 needs some further considerations about the selection of the media 989 type that best fits this specific use case. 991 The usage of two different content-types that are suitable for 992 carrying multiple notifications in a single session, is discussed in 993 the following sections. 995 4.3.4.2.1. Multipart messaging 997 As already discussed in Section 4.3.1.1 for multicasting, the 998 "multipart/*" media type is a suitable solution to deliver multiple 999 CoAP notifications within a single HTTP payload. 1001 As in the multicast case, each part of the multipart entity MAY be 1002 represented using a "message/http" media type, containing the full 1003 mapping of the single CoAP notification mapped, so that CoAP envelope 1004 informations are preserved (e.g. the response code). 1006 A more sophisticated mapping could use multipart/mixed with native or 1007 translated media type. 1009 4.3.4.2.2. Using ATOM Feeds 1011 Popular observable resources with refresh rates higher than a couple 1012 of seconds may be treated as Atom feeds [RFC4287], especially with 1013 delay tolerant user agents and where persistence is required. 1015 Figure 4 shows a resource supporting 'application/atom+xml' media- 1016 type. In such case clients can listen to update notification by 1017 regularly polling the resource via opportunely spaced GETs, i.e. 1018 driven by the advertised max-age value. 1020 4.3.4.3. Examples 1022 Figure 5 shows the interaction between an HTTP client (C), an HC 1023 proxy (P), and a CoAP server (S) for the observation of the resource 1024 "temperature" (T) available on S. 1026 C manifests its intention to observe T by including the Expect Header 1027 in the request; if P or S do not support this interaction, the 1028 request MUST fail with "417 Expectation Failed" return code. In the 1029 presented example, both P and C support this interaction, and the 1030 subscription is successful, as stated by the "206 Partial Content" 1031 return code. 1033 At every notification corresponds the emission of a HTTP chunk 1034 containing a single part, which contains a "message/http" payload 1035 containing the full mapping of the notification. When the 1036 observation is dropped by the CoAP server, the HTTP streaming session 1037 is closed. 1039 C P S 1040 | | | 1041 +---->| | GET /temperature HTTP/1.1 1042 | | | Host: node.coap.something.net 1043 | | | Expect: 206-partial-content 1044 | | | Accept: multipart/mixed 1045 | | | 1046 | +---->| CON GET 1047 | | | Uri-Path: temperature 1048 | | | Observe: 0 1049 | | | 1050 | |<----+ ACK 2.05 1051 | | | Observe: 3482 1052 | | | "22.1 C" 1053 | | | 1054 |<----+ | HTTP/1.1 206 Partial Content 1055 | | | Content-Type: multipart/mixed; boundary=notification 1056 | | | 1057 | | | XX 1058 | | | --notification 1059 | | | Content-Type: message/http 1060 | | | 1061 | | | HTTP/1.1 200 OK 1062 | | | 1063 | | | 22.1 C 1064 | | | 1065 | | | ... about 60 seconds have passed ... 1066 | | | 1067 | |<----+ NON 2.05 1068 | | | Observe: 3542 1069 | | | "21.6 C" 1070 | | | 1071 |<----+ | YY 1072 | | | --notification 1073 | | | Content-Type: message/http 1074 | | | 1075 | | | HTTP/1.1 200 OK 1076 | | | 1077 | | | 21.6 C 1078 | | | 1079 | | | ... if the server drops the relationship ... 1080 | | | 1081 | |<----+ NON 2.05 1082 | | | "21.8 C" 1083 | | | 1084 |<----+ | ZZ 1085 | | | --notification 1086 | | | Content-Type: message/http 1087 | | | 1088 | | | HTTP/1.1 200 OK 1089 | | | 1090 | | | 21.8 C 1091 | | | 1092 | | | --notification-- 1093 | | | 1094 | | | 0 1096 Figure 5: HTTP Streaming to CoAP Observe 1098 Figure 6 shows the interaction between an HTTP client (C), an HC 1099 proxy (P), and a CoAP server (S) for the observation of the resource 1100 "temperature" (T) available on S. 1102 C manifests its intention to observe T by including the Prefer Header 1103 in the request; if P or S do not support this interaction, the 1104 request silently fails if a status code "200 OK" is returned, which 1105 means that no further notification is expected on that session. 1107 In the presented example, both P and C support this interaction, and 1108 the subscription is successful, as stated by the "206 Partial 1109 Content" status code. At every notification a new response is sent 1110 to the pending client, always containing the "206 Partial Content" 1111 status code, to indicate that the observe session is still active, so 1112 that C can issue a new long-polling request immediately after this 1113 notification. 1115 If the observation relationship is dropped by S, P notifies the last 1116 received content using the "200 OK" status code, indicating that no 1117 further notification is expected on this observe session. 1119 C P S 1120 | | | 1121 +---->| | GET /temperature HTTP/1.1 1122 | | | Host: node.coap.something.net 1123 | | | Prefer: long-polling 1124 | | | 1125 | +---->| CON GET 1126 | | | Uri-Path: temperature 1127 | | | Observe: 0 1128 | | | 1129 | |<----+ ACK 2.05 1130 | | | Observe: 3482 1131 | | | "22.1 C" 1132 | | | 1133 |<----+ | HTTP/1.1 206 Partial Content 1134 | | | 1135 | | | 22.1 C 1136 | | | 1137 +---->| | GET /temperature HTTP/1.1 1138 | | | Host: node.coap.something.net 1139 | | | Prefer: long-polling 1140 | | | 1141 | | | ... about 60 seconds have passed ... 1142 | | | 1143 | |<----+ NON 2.05 1144 | | | Observe: 3542 1145 | | | "21.6 C" 1146 | | | 1147 |<----+ | HTTP/1.1 206 Partial Content 1148 | | | 1149 | | | 21.6 C 1150 | | | 1151 +---->| | GET /temperature HTTP/1.1 1152 | | | Host: node.coap.something.net 1153 | | | Prefer: long-polling 1154 | | | 1155 | | | ... if the server drops the relationship ... 1156 | | | 1157 | |<----+ NON 2.05 1158 | | | "21.8 C" 1159 | | | 1160 |<----+ | HTTP/1.1 200 OK 1161 | | | 1162 | | | 21.8 C 1164 Figure 6: HTTP Long Polling to CoAP Observe 1166 Figure 7 shows the interaction between an HTTP client (C), an HC 1167 proxy (P), and a CoAP server (S) for the observation of the resource 1168 "kitchen/temp" (T) available on S. 1170 It is assumed that the HC proxy knows that the requested resource is 1171 observable (since perhaps being asked beforehand to discover its 1172 properties as described in Figure 4.) When asked by the HTTP client 1173 to retrieve the resource, it requests an observation - in case it 1174 weren't already in place - and then sends the collected data to the 1175 client as an Atom feed. The data coming through in the constrained 1176 network is stored locally on the proxy, and forwarded when further 1177 requests are received on the HTTP side. As already said, using the 1178 Atom format has two main advantages: first, there is always a 1179 "current" feed, but there may also be a complete log made available 1180 to HTTP clients; secondly, the HTTP intermediaries can play a 1181 substantial role in absorbing a fair amount of the load on the HC 1182 proxy. The latter is a very important property when the requested 1183 resource is or becomes very popular. 1185 C P S 1186 | | | GET /kitchen/temp HTTP/1.1 1187 +------>| | Host: node.coap.something.net 1188 | | | 1189 | +------>| CON GET 1190 | | | Uri-Path: kitchen/temp 1191 | | | Observe: 0 1192 | | | 1193 | |<------+ ACK 2.05 1194 | | | Observe: 1000 1195 | | | Max-Age: 10 1196 | | | "22.3 C" 1197 | | | 1198 |<------+ | HTTP/1.1 200 OK 1199 | | | Cache-Control: max-age=10 1200 | | | ETag: "0x5555" 1201 | | | Content-Type: application/atom+xml 1202 | | | 1203 | | | 1204 | | | 1205 | | | urn:uuid:bf08203a-fbbf-49e8-bf11-3c4cff708525 1206 | | | 2012-03-07T11:14:30 1207 | | | 1208 | | | 22.3 C 1209 | | | 1210 | | | 1211 | | | 1212 | | | 1213 | | | 1214 | |<------+ NON 2.05 1215 | | | Observe: 1010 1216 | | | Max-Age: 10 1217 | | | "22.4 C" 1218 | | | 1219 +------>| | GET /kitchen/temp HTTP/1.1 1220 | | | Host: node.coap.something.net 1221 | | | 1222 | | | [...] 1223 | | | 1225 Figure 7: Observation via Atom feeds 1227 5. CoAP-HTTP implementation 1229 The CoAP protocol [I-D.ietf-core-coap] allows CoAP clients to request 1230 CoAP proxies to perform an HTTP request on their behalf. This is 1231 accomplished by the CoAP client populating an HTTP absolute URI in 1232 the 'Proxy-URI' option of the CoAP request to the CoAP proxy. An 1233 absolute URI is an HTTP URI that does not contain a fragment 1234 component [RFC3986]. The proxy then composes an HTTP request with 1235 the given URI and sends it to the appropriate HTTP origin server. 1236 The server then returns the HTTP response to the proxy, which the 1237 proxy returns to the CoAP client via a CoAP response 1239 5.1. Placement and Deployment 1241 In typical scenarios, for communication from a CoAP client to an HTTP 1242 origin server, the HC proxy is expected to be located on the client- 1243 side (CS). Specifically, the HC proxy is expected to be deployed at 1244 the edge of the constrained network as shown in Figure 8. 1246 The arguments supporting CS placement are as follows: 1248 Client/Proxy/Network configuration overhead: CoAP clients require 1249 either static proxy configuration or proxy discovery support. 1250 This overhead is simplified if the proxy is placed on the same 1251 network domain of the client. 1253 TCP/UDP: Translation between CoAP and HTTP requires also UDP to TCP 1254 mapping; UDP performance over the unconstrained Internet may not 1255 be adequate. In order to minimize the number of required 1256 retransmissions on the constrained part of the network and the 1257 overall reliability, TCP/UDP conversion SHOULD be performed as 1258 soon as possible in the network path. 1260 Caching: Efficient caching requires that all the CoAP traffic is 1261 intercepted by the same proxy, thus a CS placement, collecting all 1262 the traffic, is strategic for this need. 1264 +------+ 1265 | | 1266 | DNS | 1267 | | 1268 +------+ 1269 -------------------- 1270 // \\ 1271 / /-----\ /---\ \ 1272 / CoAP CoAP \ 1273 || client client || 1274 +----------+ \-----/ \-----/ || 1275 | HTTP/CoAP| /-----\ || 1276 | Proxy | CoAP || 1277 |(HC Proxy)| client || 1278 +------+ +----------+ \-----/ || 1279 |HTTP | || /-----\ || 1280 |Origin| || CoAP || 1281 |Server| \ client /-----\ / 1282 +------+ \ \-----/ CoAP / 1283 \ client / 1284 \\ \-----/ // 1285 ------------------ 1287 Figure 8: Client-side HC proxy deployment scenario 1289 5.2. Basic mapping 1291 The basic mapping of CoAP methods to HTTP is defined in 1292 [I-D.ietf-core-coap]. Specifically the {GET, PUT, POST, DELETE} set 1293 of CoAP methods are mapped to the equivalent HTTP methods. 1295 In general, an implementation will translate and forward CoAP 1296 requests to the HTTP origin server and translate back HTTP responses 1297 to CoAP responses, typically employing a certain amount of caching to 1298 make this translation more efficient. This section gives some hints 1299 for implementing the translation. In addition, some examples are 1300 given to illustrate the mappings. 1302 5.2.1. Payloads and Media Types 1304 CoAP supports only a subset of media types. A proxy should convert 1305 payloads and approximate content-types as closely as possible. For 1306 example, if a HTTP server returns a resource representation in "text/ 1307 plain; charset=iso-8859-1" format, the proxy should convert the 1308 payload to "text/plain; charset=utf-8" format. If conversion is not 1309 possible, the proxy can specify a media type of "application/ 1310 octet-stream". 1312 5.2.2. Max-Age and ETag Options 1314 The proxy can determine the Max-Age Option for responses to GET 1315 requests by calculating the freshness lifetime (see Section 13.2.4 of 1316 [RFC2616]) of the HTTP resource representation retrieved. The Max- 1317 Age Option for responses to POST, PUT or DELETE requests should 1318 always be set to 0. 1320 The proxy can assign entity tags to responses it sends to a client. 1321 These can be generated locally, if the proxy employs a cache, or be 1322 derived from the ETag header field in a response from the HTTP origin 1323 server, in which case the proxy can optimize future requests to the 1324 HTTP by using Conditional Requests. Note that CoAP does not support 1325 weak entity tags. 1327 5.2.3. Use of CoAP blockwise transfer 1329 A CH proxy SHOULD support CoAP blockwise transfers 1330 [I-D.ietf-core-block] to allow transport of large CoAP payloads while 1331 avoiding link-layer fragmentation in LLNs, and to cope with small 1332 datagram buffers in CoAP end-points as described in 1333 [I-D.ietf-core-block]. 1335 For improved latency a CH proxy MAY initiate a HTTP request triggered 1336 by an incoming blockwise CoAP request even when blocks of the CoAP 1337 request have only been partially received by the proxy, in cases 1338 where the Content-Length field is not going to be used in the HTTP 1339 request. This is useful especially if the network between proxy and 1340 HTTP server involves low-bandwidth links. 1342 5.2.4. HTTP Status Codes 1xx and 3xx 1344 CoAP does not have provisional responses (HTTP Status Codes 1xx) or 1345 responses indicating that further action needs to be taken (HTTP 1346 Status Codes 3xx). When a proxy receives such a response from the 1347 HTTP server, the response should cause the proxy to complete the 1348 request, for example, by following redirects. If the proxy is unable 1349 or unwilling to do so, it can return a 5.02 (Bad Gateway) error. 1351 5.2.5. Examples 1353 Figure 9 shows an example implementation of a basic CoAP GET request 1354 with an HTTP URI as the value of a Proxy-URI option. The proxy 1355 retrieves a representation of the target resource from the HTTP 1356 origin server. It converts the payload to a UTF-8 charset, 1357 calculates the Max-Age Option from the Expires header field, and 1358 derives an entity-tag from the ETag header field. 1360 C P S 1361 | | | 1362 +---------->| | CoAP Header: GET (T=CON, Code=1, MID=0x1633) 1363 | CoAP | | Token: 0x5a 1364 | Get | | Proxy-URI: http://www.example.com/foo/bar 1365 | | | 1366 | | | 1367 | +---------->| HTTP/1.1 GET /foo/bar 1368 | | HTTP | Host: www.example.com 1369 | | GET | 1370 | | | 1371 | | | 1372 |<----------+ | CoAP Header: (T=ACK, Code=0, MID=0x1633) 1373 | | | 1374 | | | 1375 | |<----------+ HTTP/1.1 200 OK 1376 | | HTTP | Date: Friday, 14 Oct 2011 15:00:00 GMT 1377 | | 200 OK | Content-Type: text/plain; charset=iso-8859-1 1378 | | | Content-Length: 11 1379 | | | Expires: Friday, 14 Oct 2011 16:00:00 GMT 1380 | | | ETag: "xyzzy" 1381 | | | Connection: close 1382 | | | 1383 | | | Hello World 1384 | | | 1385 | | | 1386 |<----------+ | CoAP Header: 2.00 OK (T=CON, Code=64, MID=0xAAFO) 1387 | CoAP | | Token: 0x5a 1388 | 2.00 OK | | C-Type: text/plain; charset=utf-8 1389 | | | Max-Age: 3600 1390 | | | ETag: 0x78797A7A79 1391 | | | Payload: "Hello World" 1392 | | | 1393 +---------->| | CoAP Header: (T=ACK, Code=0, MID=0xAAF0) 1395 Figure 9: A basic CoAP-HTTP GET request 1397 The example in Figure 10 builds on the previous example and shows an 1398 implementation of a GET request that includes a previously returned 1399 ETag Option. The proxy makes a Conditional Request to the HTTP 1400 origin server by including an If-None-Match header field in the HTTP 1401 GET Request. The CoAP response indicates that the response stored by 1402 the client is fresh. It includes a Max-Age Option calculated from 1403 the HTTP response's Expires header field. 1405 C P S 1406 | | | 1407 +---------->| | CoAP Header: GET (T=CON, Code=1, MID=0x1CBO) 1408 | CoAP | | Token: 0x7b 1409 | Get | | Proxy-URI: http://www.example.com/foo/bar 1410 | | | ETag: 0x78797A7A79 1411 | | | 1412 | | | 1413 | +---------->| HTTP/1.1 GET /foo/bar 1414 | | HTTP | Host: www.example.com 1415 | | GET | If-None-Match: "xyzzy" 1416 | | | 1417 | | | 1418 |<----------+ | CoAP Header: (T=ACK, Code=0, MID=0x1CBO) 1419 | | | 1420 | | | 1421 | |<----------+ HTTP/1.1 304 Not Modified 1422 | | HTTP | Date: Friday, 14 Oct 2011 17:00:00 GMT 1423 | | 304 | Expires: Friday, 14 Oct 2011 18:00:00 GMT 1424 | | | ETag: "xyzzy" 1425 | | | Connection: close 1426 | | | 1427 | | | 1428 |<----------+ | CoAP Header: 2.03 Valid (T=CON, Code=67, MID=0xAAFF) 1429 | CoAP | | Token: 0x7b 1430 | 2.03 | | Max-Age: 3600 1431 | | | ETag: 0x78797A7A79 1432 | | | 1433 | | | 1434 +---------->| | CoAP Header: (T=ACK, Code=0, MID=0xAAFF) 1436 Figure 10: A CoAP-HTTP GET request with an ETag Option 1438 6. Security Considerations 1440 The security concerns raised in Section 15.7 of [RFC2616] also apply 1441 to the HC proxy scenario. In fact, the HC proxy is a trusted (not 1442 rarely a transparently trusted) component in the network path. 1444 The trustworthiness assumption on the HC proxy cannot be dropped. 1445 Even if we had a blind, bi-directional, end-to-end, tunneling 1446 facility like the one provided by the CONNECT method in HTTP, and 1447 also assuming the existence of a DTLS-TLS transparent mapping, the 1448 two tunneled ends should be speaking the same application protocol, 1449 which is not the case. Basically, the protocol translation function 1450 is a core duty of the HC proxy that can't be removed, and makes it a 1451 necessarily trusted, impossible to bypass, component in the 1452 communication path. 1454 A reverse proxy deployed at the boundary of a constrained network is 1455 an easy single point of failure for reducing availability. As such, 1456 a special care should be taken in designing, developing and operating 1457 it, keeping in mind that, in most cases, it could have fewer 1458 limitations than the constrained devices it is serving. 1460 The following sub paragraphs categorize and argue about a set of 1461 specific security issues related to the translation, caching and 1462 forwarding functionality exposed by an HC proxy module. 1464 6.1. Traffic overflow 1466 Due to the typically constrained nature of CoAP nodes, particular 1467 attention SHOULD be posed in the implementation of traffic reduction 1468 mechanisms (see Section 4.2.1), because inefficient implementations 1469 can be targeted by unconstrained Internet attackers. Bandwidth or 1470 complexity involved in such attacks is very low. 1472 An amplification attack to the constrained network may be triggered 1473 by a multicast request generated by a single HTTP request mapped to a 1474 CoAP multicast resource, as considered in Section XX of 1475 [I-D.ietf-core-coap]. 1477 The impact of this amplification technique is higher than an 1478 amplification attack carried out by a malicious constrained device 1479 (i.e. ICMPv6 flooding, like Packet Too Big, or Parameter Problem on 1480 a multicast destination [RFC4732]), since it does not require direct 1481 access to the constrained network. 1483 The feasibility of this attack, disruptive in terms of CoAP server 1484 availability, can be limited by access controlling the exposed HTTP 1485 multicast resource, so that only known/authorized users access such 1486 URIs. 1488 6.2. Cross-protocol security policy mapping 1490 At the moment of this writing, CoAP and HTTP are missing any cross- 1491 protocol security policy mapping. 1493 The HC proxy SHOULD flexibly support security policies between the 1494 two protocols, possibly as part of the HC URI mapping function, in 1495 order to statically map HTTP and CoAP security policies at the proxy 1496 (see Appendix A.2 for an example.) 1498 6.3. Handling secured exchanges 1500 It is possible that the request from the client to the HC proxy is 1501 sent over a secured connection. However, there may or may not exist 1502 a secure connection mapping to the other protocol. For example, a 1503 secure distribution method for multicast traffic is complex and MAY 1504 not be implemented (see [I-D.ietf-core-groupcomm]). 1506 By default, an HC proxy SHOULD reject any secured client request if 1507 there is no configured security policy mapping. This recommendation 1508 MAY be relaxed in case the destination network is believed to be 1509 secured by other, complementary, means. E.g.: assumed that CoAP 1510 nodes are isolated behind a firewall (e.g. as the SS HC proxy 1511 deployment shown in Figure 1), the HC proxy may be configured to 1512 translate the incoming HTTPS request using plain CoAP (i.e. NoSec 1513 mode.) 1515 The HC URI mapping MUST NOT map to HTTP (see Section 3.1) a CoAP 1516 resource intended to be accessed only using HTTPS. 1518 A secured connection that is terminated at the HC proxy, i.e. the 1519 proxy decrypts secured data locally, raises an ambiguity about the 1520 cacheability of the requested resource. The HC proxy SHOULD NOT 1521 cache any secured content to avoid any leak of secured information. 1522 However in some specific scenario, a security/efficiency trade-off 1523 could motivate caching secured information; in that case the caching 1524 behavior MAY be tuned to some extent on a per-resource basis (see 1525 Section 6.2). 1527 6.4. Spoofing and Cache Poisoning 1529 In web security jargon, the "cache poisoning" verb accounts for 1530 attacks where an evil user causes the proxy server to associate 1531 incorrect content to a cached resource, which work through especially 1532 crafted HTTP requests or request/response combos. 1534 When working in CoAP NoSec mode, the use of UDP makes cache poisoning 1535 on the constrained network easy and effective, simple address 1536 spoofing by a malicious host is sufficient to perform the attack. 1537 The implicit broadcast nature of typical link-layer communication 1538 technologies used in constrained networks lead this attack to be 1539 easily performed by any host, even without the requirement of being a 1540 router in the network. The ultimate outcome depends on both the 1541 order of arrival of packets (legitimate and rogue) and the 1542 processing/discarding policy at the CoAP node; attackers targeting 1543 this weakness may have less requirements on timing, thus leading the 1544 attack to succeed with high probability. 1546 In case the threat of a rogue mote acting in the constrained network 1547 can't be winded up by appropriate procedural means, the only way to 1548 avoid such attacks is for any CoAP server to work at least in 1549 MultiKey mode with a 1:1 key with the HC proxy. SharedKey mode would 1550 just mitigate the attack, since a guessable MIDs and Tokens 1551 generation function at the HC proxy side would make it feasible for 1552 the evil mote to implement a "try until succeed" strategy. Also, 1553 (authenticated) encryption at a lower layer (MAC/PHY) could be 1554 defeated by a slightly more powerful attacker, a compromised router 1555 mote. 1557 6.5. Subscription 1559 As noted in Section 7 of [I-D.ietf-core-observe], when using the 1560 observe pattern, an attacker could easily impose resource exhaustion 1561 on a naive server who's indiscriminately accepting observer 1562 relationships establishment from clients. The converse of this 1563 problem is also present, a malicious client may also target the HC 1564 proxy itself, by trying to exhaust the HTTP connection limit of the 1565 proxy by opening multiple subscriptions to some CoAP resource. 1567 Effective strategies to reduce success of such a DoS on the HTTP side 1568 (by forcing prior identification of the HTTP client via usual web 1569 authentication mechanisms), must always be weighted against an 1570 acceptable level of usability of the exposed CoAP resources. 1572 7. Acknowledgements 1574 Special credit is given to Klaus Hartke who provided the text for 1575 Section 5 and a lot of direct input to this document. Special credit 1576 about the text in Section 5 is given to Carsten Bormann who provied 1577 parts of it. 1579 Thanks to Zach Shelby, Michele Rossi, Nicola Bui, Michele Zorzi, 1580 Peter Saint-Andre, Cullen Jennings, Kepeng Li, Brian Frank, Peter Van 1581 Der Stok, Kerry Lynn, Linyi Tian, Dorothy Gellert for helpful 1582 comments and discussions that have shaped the document. 1584 The research leading to these results has received funding from the 1585 European Community's Seventh Framework Programme [FP7/2007-2013] 1586 under grant agreement n. [251557]. 1588 8. References 1589 8.1. Normative References 1591 [I-D.ietf-core-block] 1592 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1593 draft-ietf-core-block-04 (work in progress), July 2011. 1595 [I-D.ietf-core-coap] 1596 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 1597 "Constrained Application Protocol (CoAP)", 1598 draft-ietf-core-coap-07 (work in progress), July 2011. 1600 [I-D.ietf-core-groupcomm] 1601 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1602 draft-ietf-core-groupcomm-00 (work in progress), 1603 January 2012. 1605 [I-D.ietf-core-observe] 1606 Hartke, K. and Z. Shelby, "Observing Resources in CoAP", 1607 draft-ietf-core-observe-02 (work in progress), March 2011. 1609 [I-D.ietf-httpbis-p1-messaging] 1610 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 1611 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 1612 J. Reschke, "HTTP/1.1, part 1: URIs, Connections, and 1613 Message Parsing", draft-ietf-httpbis-p1-messaging-18 (work 1614 in progress), January 2012. 1616 [I-D.ietf-httpbis-p2-semantics] 1617 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 1618 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 1619 J. Reschke, "HTTP/1.1, part 2: Message Semantics", 1620 draft-ietf-httpbis-p2-semantics-18 (work in progress), 1621 January 2012. 1623 [I-D.thomson-hybi-http-timeout] 1624 Thomson, M., Loreto, S., and G. Wilkins, "Hypertext 1625 Transfer Protocol (HTTP) Timeouts", 1626 draft-thomson-hybi-http-timeout-00 (work in progress), 1627 March 2011. 1629 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1630 Extensions (MIME) Part Two: Media Types", RFC 2046, 1631 November 1996. 1633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1634 Requirement Levels", BCP 14, RFC 2119, March 1997. 1636 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1637 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1638 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1640 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1641 Resource Identifier (URI): Generic Syntax", STD 66, 1642 RFC 3986, January 2005. 1644 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1645 Syndication Format", RFC 4287, December 2005. 1647 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 1649 8.2. Informative References 1651 [I-D.bormann-core-simple-server-discovery] 1652 Bormann, C., "CoRE Simple Server Discovery", 1653 draft-bormann-core-simple-server-discovery-00 (work in 1654 progress), March 2011. 1656 [I-D.eggert-core-congestion-control] 1657 Eggert, L., "Congestion Control for the Constrained 1658 Application Protocol (CoAP)", 1659 draft-eggert-core-congestion-control-01 (work in 1660 progress), January 2011. 1662 [I-D.shelby-core-resource-directory] 1663 Shelby, Z. and S. Krco, "CoRE Resource Directory", 1664 draft-shelby-core-resource-directory-01 (work in 1665 progress), September 2011. 1667 [I-D.snell-http-prefer] 1668 Snell, J., "Prefer Header for HTTP", 1669 draft-snell-http-prefer-12 (work in progress), 1670 February 2012. 1672 [I-D.vanderstok-core-bc] 1673 Stok, P. and K. Lynn, "CoAP Utilization for Building 1674 Control", draft-vanderstok-core-bc-04 (work in progress), 1675 July 2011. 1677 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 1678 Replication and Caching Taxonomy", RFC 3040, January 2001. 1680 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1681 Service Considerations", RFC 4732, December 2006. 1683 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 1684 "Known Issues and Best Practices for the Use of Long 1685 Polling and Streaming in Bidirectional HTTP", RFC 6202, 1686 April 2011. 1688 [W3C.HTML5] 1689 Hickson, I., "HTML5", World Wide Web Consortium WD (work 1690 in progress) WD-html5-20111018, October 2011, 1691 . 1693 Appendix A. Internal Mapping Functions (from an implementer's 1694 perspective) 1696 At least three mapping functions have been identified, which take 1697 place at different stages of the HC proxy processing chain, involving 1698 the URL, Content-Type and Security Policy translation. 1700 All these maps are required to have at least URL granularity so that, 1701 in principle, each and every requested URL may be treated as an 1702 independent mapping source. 1704 In the following, the said map functions are characterized via their 1705 expected input and output, and a simple, yet sufficiently rich, 1706 configuration syntax is suggested. 1708 In the spirit of a document providing implementation guidance, the 1709 specification of a map grammar aims at putting the basis for a 1710 reusable software component (e.g. a stand-alone C library) that many 1711 different proxy implementations can link to, and benefit from. 1713 A.1. URL Map Algorithm 1715 In case the HC proxy is a reverse proxy, i.e. it acts as the origin 1716 server in face of the served network, the URL of the resource 1717 requested by its clients (perhaps having an 'http' scheme) shall be 1718 mapped to the real resource origin (perhaps in the 'coap' scheme). 1720 In case HC is a forward proxy, no URL translation is needed since the 1721 client already knows the "real name" of the resource. 1723 An interception HC proxy, instead, MAY use the homogeneous mapping 1724 strategy (see Section 3.1.1 for details) to operate without any pre- 1725 configuration need. 1727 As noted in Appendix B of [RFC3986] any correctly formatted URL can 1728 be matched by a POSIX regular expression. By leveraging on this 1729 property, we suggest a syntax that describes the URL mapping in terms 1730 of substituting the regex-matching portions of the requested URL into 1731 the mapped URL template. 1733 E.g.: given the source regular expression 1734 '^http://example.com/coap/.*$' and destination template 'coap://$1' 1735 (where $1 stands for the first - and only in this specific case - 1736 substring matched by the regex pattern in the source), the input URL 1737 "http://example.com/coap/node1/resource2" translates to 1738 "coap://node1/resource2". 1740 This is a well established technique used in many todays web 1741 components (e.g. Django URL dispatcher, Apache mod_rewrite, etc.), 1742 which provides a compact and powerful engine to implement what 1743 essentially is an URL rewrite function. 1745 INPUT 1746 * requested URL 1748 OUTPUT 1749 * target URL 1751 SYNTAX 1752 url_map [rule name] { 1753 requested_url 1754 mapped_url 1755 } 1757 EXAMPLE 1 1758 url_map homogeneous { 1759 requested_url '^http://.*$' 1760 mapped_url 'coap//$1' 1761 } 1763 EXAMPLE 2 1764 url_map embedded { 1765 requested_url '^http://example.com/coap/.*$' 1766 mapped_url 'coap//$1' 1767 } 1769 Note that many different url_map records may be given in order to 1770 build the whole mapping function. Each of these records can be 1771 queried (in some predefined order) by the HC proxy until a match is 1772 found, or the list is exhausted. In the latter case, depending on 1773 the mapping policy (only internal, internal then external, etc.) the 1774 original request can be refused, or the same mapping query is 1775 forwarded to one or more external URL mapping components. 1777 A.2. Security Policy Map Algorithm 1779 In case the "incoming" URL has been successfully translated, the HC 1780 proxy must lookup the security policy, if any, that needs to be 1781 applied to the request/response transaction carried on the "outgoing" 1782 leg. 1784 INPUT 1785 * target URL (after URL map has been applied) 1786 * original requester identity (given by cookie, or IP address, or 1787 crypto credentials/security context, etc.) 1789 OUTPUT 1790 * security context that will be applied to access the target URL 1792 SYNTAX 1793 sec_map [rule name] { 1794 target_url -- one or more 1795 requester_id [TBD] 1796 sec_context [TBD] 1797 } 1799 EXAMPLE 1800 [TBD] 1802 A.3. Content-Type Map Algorithm 1804 In case a set of destination URLs is known as being limited in 1805 handling a narrow subset of mime types, a content-type map can be 1806 configured in order to let the HC proxy transparently handle the 1807 compatible/lossless format translation. 1809 INPUT 1810 * destination URL (after URL map has been applied) 1811 * original content-type 1813 OUTPUT 1814 * mapped content-type 1816 SYNTAX 1817 ct_map { 1818 target_url -- one or more targetURLs 1819 ct_switch -- one or more CTs 1820 } 1822 EXAMPLE 1823 ct_map { 1824 target_url '^coap://class-1-device/.*$' 1825 ct_switch */xml application/exi 1826 } 1828 Authors' Addresses 1830 Angelo P. Castellani 1831 University of Padova 1832 Via Gradenigo 6/B 1833 Padova 35131 1834 Italy 1836 Email: angelo@castellani.net 1838 Salvatore Loreto 1839 Ericsson 1840 Hirsalantie 11 1841 Jorvas 02420 1842 Finland 1844 Email: salvatore.loreto@ericsson.com 1846 Akbar Rahman 1847 InterDigital Communications, LLC 1849 Email: Akbar.Rahman@InterDigital.com 1851 Thomas Fossati 1852 KoanLogic 1853 Via di Sabbiuno 11/5 1854 Bologna 40136 1855 Italy 1857 Phone: +39 051 644 82 68 1858 Email: tho@koanlogic.com 1860 Esko Dijk 1861 Philips Research 1863 Email: esko.dijk@philips.com