idnits 2.17.1 draft-castellani-core-http-mapping-00.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 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 7 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 == 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 section of the URI is thus used internally by the HC proxy and SHOULD not be mapped to CoAP. -- The document date (July 4, 2011) is 4679 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: '0-9' is mentioned on line 805, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-06 == 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-14 == Outdated reference: A later version (-07) exists of draft-rahman-core-groupcomm-05 == 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-00 == Outdated reference: A later version (-05) exists of draft-vanderstok-core-bc-03 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group A. Castellani 3 Internet-Draft University of Padova 4 Intended status: Informational S. Loreto 5 Expires: January 5, 2012 Ericsson 6 A. Rahman 7 InterDigital Communications, LLC 8 T. Fossati 9 KoanLogic 10 E. Dijk 11 Philips Research 12 July 4, 2011 14 Best practices for HTTP-CoAP mapping implementation 15 draft-castellani-core-http-mapping-00 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 January 5, 2012. 41 Copyright Notice 43 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Cross-protocol resource identification using URIs . . . . . . 5 61 3.1. URI mapping . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1.1. Homogeneous mapping . . . . . . . . . . . . . . . . . 6 63 3.1.2. Embedded mapping . . . . . . . . . . . . . . . . . . . 7 64 4. HTTP-CoAP implementation . . . . . . . . . . . . . . . . . . . 7 65 4.1. Placement and deployment . . . . . . . . . . . . . . . . . 7 66 4.2. Basic mapping . . . . . . . . . . . . . . . . . . . . . . 9 67 4.2.1. Caching and congestion control . . . . . . . . . . . . 10 68 4.2.2. Use case: HTTP/IPv4-CoAP/IPv6 proxy . . . . . . . . . 11 69 4.3. Multiple message exchanges mapping . . . . . . . . . . . . 13 70 4.3.1. Relevant features of existing standards . . . . . . . 13 71 4.3.2. Multicast mapping . . . . . . . . . . . . . . . . . . 14 72 4.3.3. Subscription mapping . . . . . . . . . . . . . . . . . 17 73 5. CoAP-HTTP implementation . . . . . . . . . . . . . . . . . . . 17 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 6.1. Traffic overflow . . . . . . . . . . . . . . . . . . . . . 18 76 6.2. Cross-protocol security policy mapping . . . . . . . . . . 18 77 6.3. Handling secured exchanges . . . . . . . . . . . . . . . . 19 78 6.4. Spoofing and Cache Poisoning . . . . . . . . . . . . . . . 20 79 6.5. Subscription . . . . . . . . . . . . . . . . . . . . . . . 20 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 RESTful protocols, such as HTTP [RFC2616] and CoAP 89 [I-D.ietf-core-coap], can interoperate through an intermediary proxy 90 which performs cross-protocol mapping. 92 A reference about the mapping process is provided in Section 8 of 93 [I-D.ietf-core-coap]. However, depending on the involved 94 application, deployment scenario, or network topology, such mapping 95 could be realized using a wide range of intermediaries. 97 Moreover, the process of implementing such a proxy could be complex, 98 and details regarding its internal procedures and design choices 99 deserve further discussion, which is provided in this document. 101 This draft is organized as follows: 103 o Section 2 describes terminology to identify different mapping 104 approaches and the related proxy deployments; 106 o Section 3 discusses impact of the mapping on URI and describes 107 notable options; 109 o Section 4 and Section 5 respectively analyze the mapping from HTTP 110 to CoAP and viceversa; 112 o Section 6 discusses possible security impact related to the 113 mapping. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. Terminology 121 A device providing cross-protocol HTTP-CoAP mapping is called an 122 HTTP-CoAP cross-protocol proxy (HC proxy). 124 Regular HTTP proxies are usually same-protocol proxies, because they 125 can map from HTTP to HTTP. CoAP same-protocol proxies are 126 intermediaries for CoAP to CoAP exchanges. However the discussion 127 about these entities is out-of-scope of this document. 129 At least two different kinds of HC proxies exist: 131 o One-way cross-protocol proxy (1-way proxy): This proxy translates 132 from a client of a protocol to a server of another protocol but 133 not vice-versa. 135 o Two-way (or bidirectional) cross-protocol proxy (2-way proxy): 136 This proxy translates from a client of both protocols to a server 137 supporting one protocol. 139 1-way and 2-way HC proxies are realized using the following general 140 types of proxies: 142 Forward proxy (F): Is a proxy known by the client (either CoAP or 143 HTTP) used to access a specific cross-protocol server 144 (respectively HTTP or CoAP). Main feature: server(s) do not 145 require to be known in advance by the proxy (ZSC: Zero Server 146 Configuration). 148 Reverse proxy (R): Is a proxy known by the client to be the server, 149 however for a subset of resources it works as a proxy, by knowing 150 the real server(s) serving each resource. When a cross-protocol 151 resource is accessed by a client, the request will be silently 152 forwarded by the reverse proxy to the real server (running a 153 different protocol). If a response is received by the reverse 154 proxy, it will be mapped, if possible, to the original protocol 155 and sent back to the client. Main feature: client(s) do not 156 require to be known in advance by the proxy (ZCC: Zero Client 157 Configuration). 159 Transparent (or Intercepting) proxy (I): This proxy can intercept 160 any origin protocol request (HTTP or CoAP) and map it to the 161 destination protocol, without any kind of knowledge about the 162 client or server involved in the exchange. Main feature: 163 client(s) and server(s) do not require to be known in advance by 164 the proxy (ZCC and ZSC). 166 The proxy can be placed in the network at three different logical 167 locations: 169 Server-side proxy (SS): A proxy placed on the same network domain of 170 the server; 172 Client-side proxy (CS): A proxy placed on the same network domain of 173 the client; 175 External proxy (E): A proxy placed in a network domain external to 176 both endpoints, it is in the network domain neither of the client 177 nor of the server. 179 3. Cross-protocol resource identification using URIs 181 A Uniform Resource Identifier (URI) provides a simple and extensible 182 means for identifying a resource. It enables uniform identification 183 of resources via a separately defined extensible set of naming 184 schemes [RFC3986]. 186 URIs are formed of at least three components: scheme, authority and 187 path. The scheme is the first part of the URI, and it often 188 corresponds to the protocol used to access the resource. However, as 189 noted in Section 1.2.2 of [RFC3986] the scheme does not imply that a 190 particular protocol is used to access the resource. 192 Clients supporting a protocol that uses URIs to identify target 193 resources (e.g. HTTP web browsers), may support the resolution of a 194 limited set of schemes (i.e. "http:", "https:"). When such clients 195 want to interoperate with resources available in another protocol 196 (cross-protocol resources, e.g. CoAP), the existence of a URI 197 identifying the requested resource in a scheme natively supported by 198 the client, is useful for interoperability with clients handling only 199 the supported schemes. 201 Both CoAP and HTTP expose resources through a REST interface, so the 202 same resource can be made available in both protocols by simply 203 applying protocol translation. To this end the protocol by which the 204 resource is actually served is not relevant at all for a client. 206 In general two different methods can be used to access cross-protocol 207 resources, i.e. resources offered by a server using a protocol (e.g. 208 HTTP) different from the one supported by the client (e.g. CoAP), 210 Protocol-aware access: The client accesses the cross-protocol 211 resource using the URI with the native scheme using a cross- 212 protocol proxy (e.g. uses coap: scheme URI embedded in the HTTP 213 proxy request); both CoAP and HTTP support this access method. 214 HTTP defines that proxy or servers MUST accept even an absolute- 215 URI as request-target, see Section 4.1.2 of 216 [I-D.ietf-httpbis-p1-messaging]. CoAP provides Proxy-URI option 217 having absolute-URI as value, see Section 5.10.3 of 218 [I-D.ietf-core-coap]. 220 Protocol-agnostic access: The client accesses the cross-protocol 221 resource as if it were available in the protocol supported by the 222 client (e.g. uses "http:" scheme to access a CoAP resource), the 223 actual protocol translation is provided by a cross-protocol proxy. 224 In order to use this method a URI identifying an equivalent 225 resource MUST exist. 227 No URI mapping is required when using protocol-aware access, the 228 following section is focused on URI mapping techniques for protocol- 229 agnostic access. 231 3.1. URI mapping 233 When accessing cross-protocol resources in a protocol-agnostic way, 234 clients MUST use an URI with a scheme supported by the client and 235 serving to them an equivalent resource. 237 Because determination of equivalence or difference of URIs (e.g. 238 whether or not they identify the same resource) is based on string 239 comparison, URI domains using "coap:" and "http:" scheme are fully 240 distinct: resources identified by the same authority and path tuple 241 change when switching the scheme. 243 Example: Assume that the following resource exists - 244 "coap://node.coap.something.net/foo". The resource identified by 245 "http://node.coap.something.net/foo" may not exist or be not- 246 equivalent to the one identified by the "coap:" scheme. 248 If a cross-protocol URI exists providing an equivalent representation 249 of the native protocol resource, it can be available at a completely 250 different URI (in terms of authority and path). The mapping of an 251 URI between HTTP and CoAP is said HC URI mapping. 253 Example: The HC URI mapping to HTTP of the CoAP resource identified 254 by "coap://node.coap.something.net/foo" is 255 "http://node.something.net/foobar". 257 The HC URI mapping of a resource could be complex in general, and a 258 proper mechanism to statically or dynamically (discover) map the 259 resource HC URI mapping MAY be required. 261 Two methods are proposed in the following subsections, that could in 262 general reduce the complexity related to URI mapping. 264 3.1.1. Homogeneous mapping 266 The URI mapping between CoAP and HTTP is called homogeneous when the 267 resource can be identified either using "http:", or "coap:" scheme 268 without changing neither the authority or path. 270 Example: The CoAP resource "//node.coap.something.net/foo" can be 271 accessed using CoAP at the URI "coap://node.coap.something.net/foo", 272 and using HTTP at the URI "http://node.coap.something.net/foo". When 273 the resource is accessed using HTTP, the mapping from HTTP to CoAP is 274 performed by an HC proxy 275 When homogeneous HC URI mapping is available HC-Intercepting (HC-I) 276 proxies are easily implementable. 278 3.1.2. Embedded mapping 280 The mapping is said to be embedded, if the HC URI mapping of the 281 resource embeds inside it the authority and path part of the native 282 URI. 284 Example: The CoAP resource "coap://node.coap.something.net/foo" can 285 be accessed at 286 "http://hc-proxy.something.net/coap/node.coap.something.net/foo" or 287 at "http://node.coap.something.net.hc-proxy.something.net/foo". 289 It is usually selected to minimize mapping complexity in an HC 290 reverse proxy. 292 4. HTTP-CoAP implementation 294 4.1. Placement and deployment 296 In typical scenarios the HC proxy is expected to be server-side (SS), 297 in particular deployed at the edge of the constrained network. 299 The arguments supporting SS placement are the following: 301 TCP/UDP: Translation between HTTP and CoAP requires also a TCP to 302 UDP mapping; UDP performance over the unconstrained Internet may 303 not be adequate. In order to minimize the number of required 304 retransmissions and overall reliability, TCP/UDP conversion SHOULD 305 be performed at a SS placed proxy. 307 Caching: Efficient caching requires that all the CoAP traffic is 308 intercepted by the same proxy, thus an SS placement, collecting 309 all the traffic, is strategical for this need. 311 Multicast: To support using local-multicast functionalities 312 available in the constrained network, the HC proxy MAY require a 313 network interface directly attached to the constrained network. 315 +------+ 316 | | 317 | DNS | 318 | | 319 +------+ 320 -------------------- 321 // \\ 322 / /---\ /---\ \ 323 / CoAP CoAP \ 324 || \---/ \---/ || 325 +---------+ || 326 | | /---\|| 327 |HTTP/CoAP| CoAP || 328 | | \---/|| 329 +------+ +---------+ || 330 |HTTP | || /---\ || 331 |Client| || CoAP || 332 +------+ \ \---/ / 333 \ /---\ / 334 \ CoAP / 335 \\ \---/ // 336 ------------------ 338 Figure 1: Server-side HC proxy deployment scenario 340 Other important aspects involved in the selection of which type of 341 proxy deployment, whose choice impacts its placement too, are the 342 following: 344 Client/Proxy/Network configuration overhead: Forward proxies require 345 either static configuration or discovery support in every client. 346 Reverse proxies require either static configuration, server 347 discovery or embedded URI mapping in the proxy. Intercepting 348 proxies typically require single router configuration for a whole 349 network. 351 Scalability/Availability: Both aspects are typically addressed using 352 redundancy. CS deployments, due to the limited catchment area and 353 administrative-wide domain of operation, have looser requirements 354 on this. SS deployments, in dense/popular/critical environments, 355 have stricter requirements and MAY need to be replicated. 356 Stateful proxies (e.g. reverse) may be complex to replicate. 358 Discussion about security impacts of different deployments is covered 359 in Section 6. 361 Table 1 shows some interesting HC proxy deployment scenarios, and 362 notes the advantages related to each scenario. 364 +--------------------------+------+------+------+ 365 | Feature | F CS | R SS | I SS | 366 +--------------------------+------+------+------+ 367 | TCP/UDP | - | + | + | 368 | Multicast | - | + | + | 369 | Caching | - | + | + | 370 | Scalability/Availability | + | +/- | + | 371 | Configuration | - | - | + | 372 +--------------------------+------+------+------+ 374 Table 1: Interesting HC proxy deployments 376 Guidelines proposed in the previous paragraphs have been used to fill 377 out the above table. In the first three rows, it can be seen that SS 378 deployment is preferred versus CS. Scalability/Availability issues 379 can be generally handled, but some complexity may be involved in 380 reverse proxies scenarios. Configuration overhead could be 381 simplified when intercepting proxies deployments are feasible. 383 When support for legacy HTTP clients is required, it may be 384 preferrable using configuration/discovery free deployments. 385 Discovery procedures for client or proxy auto-configuration are still 386 under active-discussion: see [I-D.vanderstok-core-bc], 387 [I-D.bormann-core-simple-server-discovery] or 388 [I-D.shelby-core-resource-directory]. Static configuration of 389 multiple forward proxies is typically not feasible in existing HTTP 390 clients. 392 4.2. Basic mapping 394 The mapping of HTTP requests to CoAP and of the response back to HTTP 395 is defined in Section 8.2 of [I-D.ietf-core-coap]. 397 The mapping of a CoAP response code to HTTP is not straightforward, 398 this mapping MUST be operated accordingly to Table 4 of 399 [I-D.ietf-core-coap]. 401 No upper bound is defined for a CoAP server to provide the response, 402 thus for long delays the HTTP client or any other proxy in between 403 MAY timeout, further considerations are available in Section 7.1.4 of 404 [I-D.ietf-httpbis-p1-messaging]. 406 The HC proxy MUST define an internal timeout for each CoAP request 407 pending, because the CoAP server MAY silently die before completing 408 the request. 410 Even if the DNS protocol may not be used inside the constrained 411 network, maintaining valid DNS entries describing the hosts available 412 on such network helps offering the CoAP resources to HTTP clients. 414 An example of the usefulness of such entries is described in 415 Section 4.2.2. 417 HTTP connection pipe-lining is transparent to the CoAP network, the 418 HC proxy will sequentially serve the requests by issuing different 419 CoAP requests. 421 4.2.1. Caching and congestion control 423 The HC proxy SHOULD limit the number of requests to CoAP servers by 424 responding, where applicable, with a cached representation of the 425 resource. 427 In the case of a multicast request, because of the inherent 428 unreliable nature of the NON messages involved, and dynamic 429 membership of multicast groups, immediately responding only with 430 previously cached responses and without issuing a new request to the 431 multicast group, could lead to duplicate partial representations of 432 the multicast resource. 434 Duplicate idempotent pending requests to the same resource SHOULD in 435 general be avoided, by duplexing the response to the relevant hosts 436 without duplicating the request. 438 If the HTTP client times out and drops the HTTP session to the proxy 439 (closing the TCP connection), the HC proxy SHOULD wait for the 440 response and cache it if possible. Further idempotent requests to 441 the same resource can use the result present in cache, or if a 442 response has still to come requests will wait on the open CoAP 443 session. 445 Traffic related to resources experiencing a recurrently high access 446 rate MAY be reduced by establishing with that resources an observe 447 session [I-D.ietf-core-observe], that will keep updated the cached 448 representation of the target resource. 450 Depending upon the particular deployment MAY exist server or 451 resources highly impacted by congestion, i.e. multicast resources 452 (see Section 4.3.2), popular servers. Careful considerations are 453 required about the caching policies for those resources, also 454 considering possible security implications related to those specific 455 targets. 457 To this end when traffic reduction obtained by the caching mechanism 458 is not adequate, the HC proxy could apply stricter policing by 459 limiting the amount of aggregate traffic to the constrained network. 460 More specifically the HC proxy SHOULD pose a strict upper limit to 461 the number of concurrent CoAP request pending directed to the same 462 constrained network, further request MAY either be queued or dropped. 463 In order to successfully apply this congestion control, the HC proxy 464 SHOULD be SS placed. 466 Further discussion on congestion control can be found in 467 [I-D.eggert-core-congestion-control]. 469 4.2.2. Use case: HTTP/IPv4-CoAP/IPv6 proxy 471 This section covers the expected common use case of when an HTTP/IPv4 472 client desires to get access to a CoAP/IPv6 resource. 474 Whereas HTTP/IPv4 is today the most widely adopted communication in 475 the Internet, a pervasive deployment of constrained nodes exploiting 476 the IPv6 address space is expected. 478 Enabling direct interoperability of such technologies is valuable. 479 An HC proxy supporting IPv4/IPv6 mapping is said to be a v4/v6 proxy. 481 An HC v4/v6 proxy SHOULD always try to resolve the URI authority, and 482 SHOULD prefer using the IPv6 resolution if available. The authority 483 section of the URI is thus used internally by the HC proxy and SHOULD 484 not be mapped to CoAP. 486 Figure 2 shows an HTTP client on IPv4 (C) accessing a CoAP server on 487 IPv6 (S) through an HC proxy on IPv4/IPv6 (P). 488 "node.coap.something.net" has an A record containing the IPv4 address 489 of the HC proxy, and an AAAA record containing the IPv6 of the CoAP 490 server. 492 C P S 493 | | | 494 | | | Source: IPv4 of C 495 | | | Destination: IPv4 of P 496 +---->| | GET /foo HTTP/1.1 497 | | | Host: node.coap.something.net 498 | | | ..other HTTP headers .. 499 | | | 500 | | | Source: IPv6 of P 501 | | | Destination: IPv6 of S 502 | +---->| CON GET 503 | | | URI-Path: foo 504 | | | 505 | | | Source: IPv6 of S 506 | | | Destination: IPv6 of P 507 | |<----+ ACK 508 | | | 509 | | | ... Time passes ... 510 | | | 511 | | | Source: IPv6 of S 512 | | | Destination: IPv6 of P 513 | |<----+ CON 2.00 514 | | | "bar" 515 | | | 516 | | | Source: IPv6 of P 517 | | | Destination: IPv6 of S 518 | +---->| ACK 519 | | | 520 | | | Source: IPv4 of P 521 | | | Destination: IPv4 of C 522 |<----+ | HTTP/1.1 200 OK 523 | | | .. other HTTP headers .. 524 | | | 525 | | | bar 526 | | | 528 Figure 2: HTTP/IPv4 to CoAP/IPv6 mapping 530 The proposed example shows the HC proxy operating also the mapping 531 between IPv4 to IPv6 using the authority information available in any 532 HTTP 1.1 request. Thus IPv6 connectivity is not required at the HTTP 533 client when accessing a CoAP server over IPv6 only, which is a 534 typical expected use case. 536 When P is an intercepting HC proxy, the CoAP request SHOULD have the 537 IPv6 address of C as source (IPv4 can always be mapped into IPv6). 539 The described solution takes into account only the HTTP/IPv4 clients 540 accessing CoAP/IPv6 servers; this solution does not provide a full 541 fledged mapping from HTTP to CoAP. 543 In order to obtain a working deployment for HTTP/IPv6 clients, a 544 different HC proxy access method may be required, or Internet AAAA 545 records should not point to the node anymore (the HC proxy should use 546 a different DNS database pointing to the node). 548 When an HC intercepting proxy deployment is used this solution is 549 fully working even with HTTP/IPv6 clients. 551 4.3. Multiple message exchanges mapping 553 This section discusses the mapping of some advanced CoAP features 554 (e.g. multicast, observe) to HTTP which involves the need to 555 asynchronously deliver multiple responses within the same HTTP 556 request. 558 4.3.1. Relevant features of existing standards 560 Various features provided by existing standards are useful to 561 efficiently represent sessions involving multiple messages. 563 4.3.1.1. Multipart messages 565 In particular the "multipart/*" media type, defined in Section 5.1 of 566 [RFC2046], is a suitable solution to deliver multiple CoAP responses 567 within a single HTTP payload. Each part of a multipart entity SHOULD 568 be represented using "message/http" media type containing the full 569 mapping of a single CoAP response as previously described. 571 4.3.1.2. Immediate message delivery 573 An HC proxy may prefer to transfer each CoAP response immediately 574 after its reception. This is possible thanks to the HTTP Transfer- 575 Encoding "chunked", that enables transferring single responses 576 without any further delay. 578 A detailed discussion on the use of chunked Transfer-Encoding to 579 stream data over HTTP can be found in [RFC6202]. Large delays 580 between chunks can lead the HTTP session to timeout, more details on 581 this issue can be found in [I-D.thomson-hybi-http-timeout]. 583 The HC proxy MAY reduce internal buffering by providing responses to 584 HTTP client without any delay; each CoAP response can be immediately 585 streamed using HTTP chunked Transfer-Encoding. This chunked encoding 586 was not shown in order to simplify Figure 3, where the proxy returns 587 all responses in one payload after a timeout expires. An example 588 showing immediate delivery of CoAP responses using chunks is provided 589 in Section 4.3.3, while describing its application to an observe 590 session. 592 4.3.1.3. Detailing source information 594 Under some circumstance responses may come from different sources 595 (i.e. responses to a multicast request); in this case details about 596 the actual source of each CoAP response SHOULD be provided to the 597 client. Source information can be represented using HTTP Web Linking 598 as defined in [RFC5988], by adding the actual source URI into each 599 response using Link option with "via" relation type. 601 4.3.2. Multicast mapping 603 In order to establish a multicast communication such a feature should 604 be offered either by the network (i.e. IP multicast, link-layer 605 multicast, etc.) or by a gateway (i.e. the HC proxy). Rationale on 606 the methods available to obtain such a feature is out-of-scope of 607 this document, and extensive discussion of group communication 608 techniques is available in [I-D.rahman-core-groupcomm]. 610 Additional considerations related to handling multicast requests 611 mapping are detailed in the following sections. 613 4.3.2.1. URI identification and mapping 615 In order to successfully handle a multicast request, the HC proxy 616 MUST successfully perform the following tasks on the URI: 618 Identification: The HC proxy MUST understand whether the requested 619 URI identifies a group of nodes. 621 Mapping: The HC proxy MUST know how to distribute the multicast 622 request to involved servers; this process is specific of the group 623 communication technology used. 625 When using IPv6 multicast paired with DNS, the mapping to IPv6 626 multicast is simply done using DNS resolution. If the group 627 management is performed at the proxy, the URI or part of it (i.e. the 628 authority) can be mapped using some static or dynamic table available 629 at the HC proxy. In Section 3.5 of [I-D.rahman-core-groupcomm] 630 discusses a method to build and maintain a local table of multicast 631 authorities. 633 4.3.2.2. Request handling 635 When the HC proxy receives a request to a URI that has been 636 successfully identified and mapped to a group of nodes, it SHOULD 637 start a multicast proxying operation, if supported by the proxy. 639 Multicast request handling consists of the following steps: 641 Multicast TX: The HC proxy sends out the request on the CoAP side by 642 using the methods offered by the specific group communication 643 technology used in the constrained network; 645 Collecting RXs: The HC proxy collects every response related to the 646 request; 648 Timeout: The HC proxy will pay special attention in multicast 649 timing, detailed discussion about timing depends upon the 650 particular group communication technology used; 652 Distributing RXs to the client: The HC proxy can distribute the 653 responses in two different ways: batch delivering them at the end 654 of the process or on timeout, or immediately delivering them as 655 they are available. Batch requires more caching and introduces 656 delays but may lead to lower TCP overhead and simpler processing. 657 Immediate is the converse. A trade-off solution of partial batch 658 delivery may also be feasible and efficient in some circumstances. 660 4.3.2.3. Example 662 Figure 3 shows an HTTP client (C) requesting the resource "/foo" to a 663 group of CoAP servers (S1/S2/S3) through an HC proxy (P) which uses 664 IP multicast to send the corresponding CoAP request. 666 C P S1 S2 S3 667 | | | | | 668 +---->| | | | GET /foo HTTP/1.1 669 | | | | | Host: group-of-nodes.coap.something.net 670 | | | | | .. other HTTP headers .. 671 | | | | | 672 | +---->|---->|---->| NON GET 673 | | | | | URI-Path: foo 674 | | | | | 675 | |<----------+ | NON 2.00 676 | | | | | "S2" 677 | | | | | 678 | | X---------------+ NON 2.00 679 | | | | | "S3" 680 | | | | | 681 | |<----+ | | NON 2.00 682 | | | | | "S1" 683 | | | | | 684 | | | | | ... Timeout ... 685 | | | | | 686 |<----+ | | | HTTP/1.1 200 OK 687 | | | | | Content-Type: multipart/mixed; boundary="response" 688 | | | | | .. other HTTP headers .. 689 | | | | | 690 | | | | | --response 691 | | | | | Content-Type: message/http 692 | | | | | 693 | | | | | HTTP/1.1 200 OK 694 | | | | | Link: ; rel=via 695 | | | | | 696 | | | | | S2 697 | | | | | 698 | | | | | --response 699 | | | | | Content-Type: message/http 700 | | | | | 701 | | | | | HTTP/1.1 200 OK 702 | | | | | Link: ; rel=via 703 | | | | | 704 | | | | | S1 705 | | | | | 706 | | | | | --response-- 707 | | | | | 709 Figure 3: Unicast HTTP to multicast CoAP mapping 711 The example proposed in the above diagram does not make any 712 assumption on which underlying group communication technology is 713 available in the constrained network. Some detailed discussion is 714 provided about it along the following lines. 716 C makes a GET request to group-of-nodes.coap.something.net. This 717 domain name MAY either resolve to the address of P, or to the IPv6 718 multicast address of the nodes (if IP multicast is supported and P is 719 an intercepting proxy), or the proxy P is specifically known by the 720 client that sends this request to it. 722 To successfully start multicast proxying operation, the HC proxy MUST 723 know that the destination URI involves a group of CoAP servers, e.g. 724 the authority group-of-nodes.coap.something.net is known to identify 725 a group of nodes either by using an internal lookup table, using DNS 726 paired with IPv6 multicast, or by using some other special technique. 728 A specific implementation option is proposed to further explain the 729 proposed example. Assume that DNS is configured such that all 730 subdomain queries to coap.something.net, such as group-of- 731 nodes.coap.something.net, resolve to the address of P. P performs the 732 HC URI mapping by removing the "coap" subdomain from the authority 733 and by switching the scheme from "http" to "coap" (result: 734 "coap://group-of-node.something.net/foo"); "group-of- 735 nodes.something.net" is resolved to an IPv6 multicast address to 736 which S1, S2 and S3 belong. The proxy handles this request as 737 multicast and sends the request "GET /foo" to the multicast group . 739 4.3.3. Subscription mapping 741 TBD 743 5. CoAP-HTTP implementation 745 Discussion about CoAP-HTTP mapping implementation considerations is 746 available in Section 3 of [I-D.hartke-core-coap-http]. 748 6. Security Considerations 750 The security concerns raised in Section 15.7 of [RFC2616] also apply 751 to the HC proxy scenario. In fact, the HC proxy is a trusted (not 752 rarely a transparently trusted) component in the network path. Also, 753 a reverse proxy deployed at the boundary of constrained network is an 754 easy single point of failure for reducing availability. As such, a 755 special care should be taken in designing, developing and operating 756 it. In most cases it could have fewer constraints than the 757 constrained devices. 759 The following sub paragraphs categorize and argue about a set of 760 specific security issues related to the translation, caching and 761 forwarding functionality exposed by an HC proxy module. 763 6.1. Traffic overflow 765 Due to the generally constrained nature of a CoAP network, particular 766 attention SHOULD be posed in the implementation of traffic reduction 767 mechanisms (see Section 4.2.1), because inefficient implementations 768 can be targeted by unconstrained Internet attackers. Bandwidth or 769 complexity involved in such attacks is very low. 771 An amplification attack to the constrained network MAY be triggered 772 by a multicast request generated by a single HTTP request mapped to a 773 CoAP multicast resource, as considered in Section XX of 774 [I-D.ietf-core-coap]. 776 The impact of this amplification technique is higher than an 777 amplification attack carried out by a malicious constrained device 778 (i.e. ICMPv6 flooding, like Packet Too Big, or Parameter Problem on 779 a multicast destination [RFC4732]), since it does not require direct 780 access to the constrained network. 782 The feasibility of this attack, disruptive in terms of CoAP server 783 availability, can be limited by access controlling the exposed HTTP 784 multicast resource, so that only known/authorized users access such 785 URIs. 787 6.2. Cross-protocol security policy mapping 789 At the moment of this writing, CoAP and HTTP are missing any cross- 790 protocol security policy mapping. 792 The HC proxy SHOULD flexibly support security policies between the 793 two protocols, possibly as part of the HC URI mapping function, in 794 order to statically map HTTP and CoAP security policies at the proxy. 796 Example: This can be provided using mod_rewrite-like syntax: 798 Sec_Context_DTLS_1 { 799 # define credentials, supported ciphersuite, etc. 800 } 802 # Map 'https://my/mote-5/path_and_query' to 803 # 'coap://mote-5/path_and_query' using the 804 # security policy defined in 'Sec_Context_DTLS_1' 805 MapRule ^https://my/mote-([0-9])/(.*$) \ 806 coap://mote-$1/$2 \ 807 ${Sec_Context_DTLS_1} 809 # Apply homogeneous mapping of URLs in the http schema, 810 # with no security policy. 811 MapRule ^http://.*$ \ 812 coap://$1 \ 813 NoSec 815 6.3. Handling secured exchanges 817 It is possible that the request from the client to the HC proxy is 818 sent over a secured connection. However, there may or may not exist 819 a secure connection mapping to the other protocol. For example, a 820 secure distribution method for multicast traffic is complex and MAY 821 not be implemented (see [I-D.rahman-core-groupcomm]). 823 An HC proxy SHOULD reject secured request if there is not a 824 corresponding secure mapping. The HC proxy MAY still decide to 825 process an incoming secured request, even in the absence of a secure 826 mapping. 828 Example: Assume that CoAP nodes are isolated behind a secure firewall 829 (e.g. as the SS HC proxy deployment shown in Figure 1), and the HC 830 proxy cannot perform any secure CoAP mapping. In this scenario, the 831 HC proxy may be configured to translate anyway the incoming HTTPS 832 request using CoAP NoSec mode, as the internal CoAP network is 833 believed to be secure. 835 The HC URI mapping MUST NOT map to HTTP (see Section 3.1) a CoAP 836 resource intended to be accessed only using HTTPS. 838 A secured connection that is terminated at the HC proxy, i.e. the 839 proxy decrypts secured data locally, raises an ambiguity about the 840 cacheability of the requested resource. The HC proxy SHOULD NOT 841 cache any secured content to avoid any leak of secured information. 842 However in some specific scenario, a security/efficiency trade-off 843 could motivate caching secured information; in that case the caching 844 behavior MAY be tuned to some extent on a per-resource basis (see 845 Section 6.2). 847 6.4. Spoofing and Cache Poisoning 849 In web security jargon, the "cache poisoning" verb accounts for 850 attacks where an evil user causes the proxy server to associate 851 incorrect content to a cached resource, which work through especially 852 crafted HTTP requests or request/response combos. 854 When working in CoAP NoSec mode, the use of UDP makes cache poisoning 855 on the constrained network easy and effective, simple address 856 spoofing by a malicious host is sufficient to perform the attack. 857 The implicit broadcast nature of typical link-layer communication 858 technologies used in constrained networks lead this attack to be 859 easily performed by any host, even without the requirement of being a 860 router in the network. The ultimate outcome depends on both the 861 order of arrival of packets (legitimate and rogue); attackers 862 targeting this weakness may have less requirements on timing, thus 863 leading the attack to succeed with high probability. 865 In case the threat of a rogue mote acting in the constrained network 866 can't be winded up by appropriate procedural means, the only way to 867 avoid such attacks is for any CoAP server to work at least in 868 MultiKey mode with a 1:1 key with the HC proxy. SharedKey mode would 869 just mitigate the attack, since a guessable MIDs and Tokens 870 generation function at the HC proxy side would make it feasible for 871 the evil mote to implement a "try until succeed" strategy. Also, 872 (authenticated) encryption at a lower layer (MAC/PHY) could be 873 defeated by a slightly more powerful attacker, a compromised router 874 mote. 876 6.5. Subscription 878 As noted in Section 7 of [I-D.ietf-core-observe], when using the 879 observe pattern, an attacker could easily impose resource exhaustion 880 on a naive server who's indiscriminately accepting observer 881 relationships establishment from clients. The converse of this 882 problem is also present, a malicious client may also target the HC 883 proxy itself, by trying to exhaust the HTTP connection limit of the 884 proxy by opening multiple subscriptions to some CoAP resource. 886 Effective strategies to reduce success of such a DoS on the HTTP side 887 (by forcing prior identification of the HTTP client via usual web 888 authentication mechanisms), must always be weighted against an 889 acceptable level of usability of the exposed CoAP resources. 891 7. Acknowledgements 893 Thanks to Klaus Hartke, Zach Shelby, Carsten Bormann, Michele Rossi, 894 Nicola Bui, Michele Zorzi, Peter Saint-Andre, Cullen Jennings, Kepeng 895 Li, Brian Frank, Peter Van Der Stok, Kerry Lynn, Linyi Tian, Dorothy 896 Gellert for helpful comments and discussions that have shaped the 897 document. 899 8. References 901 8.1. Normative References 903 [I-D.ietf-core-coap] 904 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 905 "Constrained Application Protocol (CoAP)", 906 draft-ietf-core-coap-06 (work in progress), May 2011. 908 [I-D.ietf-core-observe] 909 Hartke, K. and Z. Shelby, "Observing Resources in CoAP", 910 draft-ietf-core-observe-02 (work in progress), March 2011. 912 [I-D.ietf-httpbis-p1-messaging] 913 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 914 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 915 "HTTP/1.1, part 1: URIs, Connections, and Message 916 Parsing", draft-ietf-httpbis-p1-messaging-14 (work in 917 progress), April 2011. 919 [I-D.rahman-core-groupcomm] 920 Rahman, A. and E. Dijk, "Group Communication for CoAP", 921 draft-rahman-core-groupcomm-05 (work in progress), 922 May 2011. 924 [I-D.thomson-hybi-http-timeout] 925 Thomson, M., Loreto, S., and G. Wilkins, "Hypertext 926 Transfer Protocol (HTTP) Timeouts", 927 draft-thomson-hybi-http-timeout-00 (work in progress), 928 March 2011. 930 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 931 Extensions (MIME) Part Two: Media Types", RFC 2046, 932 November 1996. 934 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 935 Requirement Levels", BCP 14, RFC 2119, March 1997. 937 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 938 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 939 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 941 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 942 Resource Identifier (URI): Generic Syntax", STD 66, 943 RFC 3986, January 2005. 945 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 947 8.2. Informative References 949 [I-D.bormann-core-simple-server-discovery] 950 Bormann, C., "CoRE Simple Server Discovery", 951 draft-bormann-core-simple-server-discovery-00 (work in 952 progress), March 2011. 954 [I-D.eggert-core-congestion-control] 955 Eggert, L., "Congestion Control for the Constrained 956 Application Protocol (CoAP)", 957 draft-eggert-core-congestion-control-01 (work in 958 progress), January 2011. 960 [I-D.hartke-core-coap-http] 961 Hartke, K., "Accessing HTTP resources over CoAP", 962 draft-hartke-core-coap-http-00 (work in progress), 963 March 2011. 965 [I-D.shelby-core-resource-directory] 966 Shelby, Z. and S. Krco, "CoRE Resource Directory", 967 draft-shelby-core-resource-directory-00 (work in 968 progress), June 2011. 970 [I-D.vanderstok-core-bc] 971 Stok, P. and K. Lynn, "CoAP Utilization for Building 972 Control", draft-vanderstok-core-bc-03 (work in progress), 973 March 2011. 975 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 976 Service Considerations", RFC 4732, December 2006. 978 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 979 "Known Issues and Best Practices for the Use of Long 980 Polling and Streaming in Bidirectional HTTP", RFC 6202, 981 April 2011. 983 Authors' Addresses 985 Angelo P. Castellani 986 University of Padova 987 Via Gradenigo 6/B 988 Padova 35131 989 Italy 991 Email: angelo@castellani.net 993 Salvatore Loreto 994 Ericsson 995 Hirsalantie 11 996 Jorvas 02420 997 Finland 999 Email: salvatore.loreto@ericsson.com 1001 Akbar Rahman 1002 InterDigital Communications, LLC 1004 Email: Akbar.Rahman@InterDigital.com 1006 Thomas Fossati 1007 KoanLogic 1008 Via di Sabbiuno 11/5 1009 Bologna 40136 1010 Italy 1012 Phone: +39 051 644 82 68 1013 Email: tho@koanlogic.com 1015 Esko Dijk 1016 Philips Research 1018 Email: esko.dijk@philips.com