| CoRE Working Group | A.P. Castellani |
| Internet-Draft | University of Padova |
| Intended status: Informational | S. Loreto |
| Expires: January 03, 2013 | Ericsson |
| A. Rahman | |
| InterDigital Communications, LLC | |
| T. Fossati | |
| KoanLogic | |
| E. Dijk | |
| Philips Research | |
| July 04, 2012 |
Best Practices for HTTP-CoAP Mapping Implementation
draft-castellani-core-http-mapping-05
This draft provides reference information for HTTP-CoAP proxy implementors. It details deployment options, discusses possible approaches for URI mapping, and provides useful considerations related to protocol translation.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 03, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
RESTful protocols, such as HTTP [RFC2616] and CoAP [I-D.ietf-core-coap], can interoperate through an intermediary proxy which performs cross-protocol mapping.
A reference about the mapping process is provided in [I-D.ietf-core-coap]. However, depending on the involved application, deployment scenario, or network topology, such mappings can be realized using a wide range of intermediaries.
Moreover, the process of implementing such a proxy can be complex, and details regarding its internal procedures and design choices require further elaboration, which is provided in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Cross-Protocol Proxy (or Cross Proxy): a cross-protocol mapping proxy, typically a HTTP-CoAP mapping proxy in the context of this document.
HC URI mapping: mapping of a HTTP URI to an equivalent CoAP URI
One-way and two-way cross proxies can be realized using the following general types of proxies:
A server-side (SS) proxy is placed in the same network domain of the server; Conversely a client-side (CS) is in the same network domain of the client. In any other case than SS or CS, the proxy is said to be External (E).
A Uniform Resource Identifier (URI) provides a simple and extensible means for identifying a resource. It enables uniform identification of resources via a separately defined extensible set of naming schemes [RFC3986].
URIs are formed of at least three components: scheme, authority and path. The scheme is the first part of the URI, and it often corresponds to the protocol used to access the resource. However, as noted in Section 1.2.2 of [RFC3986] the scheme does not imply that a particular protocol is used to access the resource.
Both CoAP and HTTP implement the REST paradigm, so, in general, the same web resource, i.e., identified by the same URI, can be accessed using either one of these protocols.
This could happen as long as the URI scheme of the target resource is supported by the client; however, web clients may support only a limited set of schemes. Example: HTTP clients typically support only 'http' and 'https' schemes.
Whenever does not exist an URI to access the resource with a scheme supported by the client, communication may still happen if the cross proxy supports mapping URIs to a supported scheme. The involved process is discussed in the following section.
URI Mapping: the act of providing an alternative URI to access a target resource.
Example: Assume that the target resource is "coap://node.coap.something.net/foo". A possible URI mapping could be "http://node.something.net/foobar".
In the previous example the scheme changes between the mapped URI and the original one; this special kind of URI is defined here as cross-protocol URI (or cross URI).
Cross proxies MAY provide cross URI to allow accessing them to clients supporting only a limited set of schemes.
If a cross-protocol URI exists, authority and path parts of the URI may change as well.
Example: Assume that the following resource exists - "coap://node.coap.something.net/foo". The resource identified by "http://node.coap.something.net/foo" may not exist or be non-equivalent to the one identified by the 'coap' scheme.
The process of providing cross URIs could be complex, since a proper mechanism to statically or dynamically (discover) map the resource is needed.
Two static HC URI mappings are discussed in the following subsections.
The URI mapping between CoAP and HTTP is called homogeneous, if the same resource is identified by URIs with different schemes.
Example: The CoAP resource "//node.coap.something.net/foo" identified either by the URI "coap://node.coap.something.net/foo", and or by the URI "http://node.coap.something.net/foo" is the same. When the resource is accessed using HTTP, the mapping from HTTP to CoAP is performed by a cross proxy
When homogeneous cross URIs are available, HTTP-CoAP Interception Cross Proxies are easily implementable.
When the HC URI mapping of the resource embeds inside it the authority and path part of the native URI, then the mapping is said to be embedded.
Example: The CoAP resource "coap://node.coap.something.net/foo" can be accessed at "http://hc-proxy.something.net/coap/node.coap.something.net/foo".
This mapping technique can be used to reduce the mapping complexity in an HTTP-CoAP Reverse Cross Proxy.
The mapping of HTTP requests to CoAP and of the response back to HTTP is defined in Section 8.2 of [I-D.ietf-core-coap].
The mapping of a CoAP response code to HTTP is not straightforward, this mapping MUST be operated according to Table 4 of [I-D.ietf-core-coap].
No temporal upper bound is defined for a CoAP server to provide the response, thus for long delays the HTTP client or any other proxy in between MAY timeout. Further discussion is available in Section 7.1.4 of [I-D.ietf-httpbis-p1-messaging].
The cross proxy MUST define an internal timeout for each pending CoAP request, because the CoAP server may silently die before completing the request.
Even if the DNS protocol may not be used inside the constrained network, having valid DNS entries for constrained hosts, where possible, MAY help HTTP clients to access the resources offered by them.
HTTP connection pipelining (section 7.1.2.2 of [I-D.ietf-httpbis-p1-messaging]) is transparent to the CoAP network: the cross proxy will sequentially serve the pipelined requests by issuing different CoAP requests.
HTTP-CoAP Reverse Cross (HCRC) Proxy is accessed by web clients only supporting HTTP, and handles their requests directed to CoAP servers by mapping them to CoAP, and mapping back the received response to HTTP. This mechanism is transparent to the client, as it may assume that is communicating with a regular HTTP server.
Typically, the HCRC Proxy is expected to be located server-side (SS), in particular deployed at the edge of the constrained network. The arguments supporting SS placement in this case are the following:
+------+
| |
| DNS |
| |
+------+
--------------------
/ \
/ /-----\ /-----\ \
/ CoAP CoAP \
/ server server \
|| \-----/ \-----/ ||
+----------+ ||
| HTTP/CoAP| /-----\ ||
| Cross | CoAP ||
| Proxy | server ||
+------+ +----------+ \-----/ ||
|HTTP | || /-----\ ||
|Client| || CoAP ||
+------+ \ server /
\ \-----/ /
\ /-----\ /
\ CoAP /
\ server /
\ \-----/ /
----------------
Other important aspects involved in the selection of which type of proxy deployment, whose choice impacts its placement too, are the following:
Discussion about security impacts of different deployments is covered in Section 8.
Table 1 shows some interesting cross proxy deployment scenarios, and notes the advantages related to each scenario.
| Feature | F CS | R SS | I SS |
|---|---|---|---|
| TCP/UDP | - | + | + |
| Multicast | - | + | + |
| Caching | - | + | + |
| Scalability/Availability | + | +/- | + |
| Configuration | - | - | + |
Guidelines proposed in the previous paragraphs have been used to fill out the above table. In the first three rows, it can be seen that SS deployment is preferred versus CS. Scalability/Availability issues can be generally handled, but some complexity may be involved in reverse proxies scenarios. Configuration overhead could be simplified when interception proxies deployments are feasible.
When support for legacy HTTP clients is required, it may be preferable using configuration/discovery free deployments. Discovery procedures for client or proxy auto-configuration are still under active-discussion: see [I-D.vanderstok-core-bc], [I-D.bormann-core-simple-server-discovery] or [I-D.shelby-core-resource-directory]. Static configuration of multiple forward proxies is typically not feasible in existing HTTP clients.
The cross proxy SHOULD limit the number of requests to CoAP servers by responding, where applicable, with a cached representation of the resource.
Duplicate idempotent pending requests to the same resource SHOULD in general be avoided, by duplexing the response to the relevant hosts without duplicating the request.
If the HTTP client times out and drops the HTTP session to the proxy (closing the TCP connection), the cross proxy SHOULD wait for the CoAP response and cache it if possible. Further idempotent requests to the same resource can use the result present in cache, or, if a response has still to come, requests will wait on the open CoAP session.
Resources experiencing a high access rate coupled with high volatility MAY be observed [I-D.ietf-core-observe] by the cross proxy to keep their cached representation fresh while minimizing the number of needed messages. See Section 5.4 for a heuristic that enables the cross proxy to decide whether observing is a more convenient strategy than ordinary refreshing via Max-Age/ETag-based mechanisms.
Specific deployments may show highly congested servers/resources -- e.g. popular servers, etc. A careful analysis is required to pick the correct caching policy involving these resources, also taking into consideration the security implications that may impact these targets specifically, and the constrained network in general.
To this end when traffic reduction obtained by the caching mechanism is not adequate, the cross proxy could apply stricter policing by limiting the amount of aggregate traffic to the constrained network. In particular, the cross proxy SHOULD pose a rigid upper limit to the number of concurrent CoAP requests pending on the same constrained network; further request MAY either be queued or dropped. In order to efficiently apply this congestion control, the cross proxy SHOULD be SS placed.
There are cases where using the CoAP observe protocol to handle proxy cache refresh may be preferable to the validation mechanism based on ETag's defined in section 5.6.2 of [I-D.ietf-core-coap]. Such scenarios include, but are not limited to, sleeping nodes -- with possibly high variance in requests' distribution -- which would greatly benefit from a server driven cache update mechanism. Ideal candidates would also be the crowded or very low throughput networks, where reduction of the total number of exchanged messages is an important requirement.
This subsection aims at providing a practical evaluation method to decide whether the refresh of a cached resource R is more efficiently handled via ETag validation or by establishing an observation on R.
Let T_R be the mean time between two client requests to resource R, let F_R be the freshness lifetime of R representation, and let M_R be the total number of messages exchanged towards resource R. If we assume that the initial cost for establishing the observation is negligible, an observation on R reduces M_R iff T_R < 2*F_R with respect to using ETag validation, that is iff the mean arrival time of requests for resource R is greater than half the refresh rate of R.
When using observations M_R is always upper bounded by 2*F_R: in the constrained network no more than 2*F_R messages will be generated towards resource R.
Proof: Let T be the evaluated interval of time, let M_Ro be the total number of messages exchanged towards resource R using observation, and let M_Re be the total number of messages exchanged towards resource R using ETag validation. The following equations hold M_Re = T*2/T_R, M_Ro = T/F_R. M_Ro < M_Re iff 1/F_R < 2/T_R, that is T_R < 2*F_R. The amount of messages saved using observation is T*(2*F_R-T_R)/(T_R*F_R).
Example: assume that F_R is one second and T_R is 1.5 seconds. Since 1.5 is lower than 2*1, an observation on R reduces M_R. In a single day of usage, 28800 messages will be saved if the cross proxy establishes an observation on R. The single message cost required to establish this observation is negligible.
A cross proxy SHOULD support CoAP blockwise transfers [I-D.ietf-core-block] to allow transport of large CoAP payloads while avoiding link-layer fragmentation in LLNs, and to cope with small datagram buffers in CoAP end-points as described in [I-D.ietf-core-coap]. A cross proxy SHOULD attempt to retry a CoAP PUT or POST request with a payload using blockwise transfer if the destination CoAP server responded with 4.13 (Request Entity Too Large) to the original request. A cross proxy SHOULD attempt to use blockwise transfer when sending a CoAP PUT or POST request message that is larger than BLOCKWISE_THRESHOLD. The value of BLOCKWISE_THRESHOLD is implementation-specific, for example it may set by an administrator, preset to a known or typical UDP datagram buffer size for CoAP end-points, to N times the size of a link-layer frame where e.g. N=5, preset to a known IP MTU value, or set to a known Path MTU value.
For improved latency a cross proxy MAY initiate a blockwise CoAP request triggered by an incoming HTTP request even when the HTTP request message has not yet been fully received, but enough data has been received to send one or more data blocks to a CoAP server already.
The CoAP protocol [I-D.ietf-core-coap] allows CoAP clients to request CoAP proxies to perform an HTTP request on their behalf. This is accomplished by the CoAP client populating an HTTP absolute URI in the 'Proxy-URI' option of the CoAP request to the CoAP proxy. An HTTP absolute URI is an HTTP URI that does not contain a fragment component [RFC3986]. The proxy then composes an HTTP request with the given URI and sends it to the appropriate HTTP origin server. The server then returns the HTTP response to the proxy, which the proxy returns to the CoAP client via a CoAP response.
The basic mapping of CoAP methods to HTTP is defined in [I-D.ietf-core-coap]. Specifically the {GET, PUT, POST, DELETE} set of CoAP methods are mapped to the equivalent HTTP methods.
In general, an implementation will translate and forward CoAP requests to the HTTP origin server and translate back HTTP responses to CoAP responses, typically employing a certain amount of caching to make this translation more efficient.
The next sections give some hints and examples for implementing the translation.
CoAP supports only a subset of media types. A proxy should convert payloads and approximate content-types as closely as possible. For example, if a HTTP server returns a resource representation in "text/plain; charset=iso-8859-1" format, the proxy should convert the payload to "text/plain; charset=utf-8" format. If conversion is not possible, the proxy can specify a media type of "application/octet-stream".
The proxy can determine the Max-Age Option for responses to GET requests by calculating the freshness lifetime (see Section 13.2.4 of [RFC2616]) of the HTTP resource representation retrieved. The Max-Age Option for responses to POST, PUT or DELETE requests should always be set to 0.
The proxy can assign entity tags to responses it sends to a client. These can be generated locally, if the proxy employs a cache, or be derived from the ETag header field in a response from the HTTP origin server, in which case the proxy can optimize future requests to the HTTP by using Conditional Requests. Note that CoAP does not support weak entity tags.
A CoAP-to-HTTP cross proxy SHOULD support CoAP blockwise transfers [I-D.ietf-core-block] to allow transport of large CoAP payloads while avoiding link-layer fragmentation in LLNs, and to cope with small datagram buffers in CoAP end-points as described in [I-D.ietf-core-block].
For improved latency a CoAP-to-HTTP cross proxy MAY initiate a HTTP request triggered by an incoming blockwise CoAP request even when blocks of the CoAP request have only been partially received by the proxy, in cases where the Content-Length field is not going to be used in the HTTP request. This is useful especially if the network between proxy and HTTP server involves low-bandwidth links.
CoAP does not have provisional responses (HTTP Status Codes 1xx) or responses indicating that further action needs to be taken (HTTP Status Codes 3xx). When a proxy receives such a response from the HTTP server, the response should cause the proxy to complete the request, for example, by following redirects. If the proxy is unable or unwilling to do so, it can return a 5.02 (Bad Gateway) error.
This memo includes no request to IANA.
The security concerns raised in Section 15.7 of [RFC2616] also apply to the cross proxy scenario. In fact, the cross proxy is a trusted (not rarely a transparently trusted) component in the network path.
The trustworthiness assumption on the cross proxy cannot be dropped. Even if we had a blind, bi-directional, end-to-end, tunneling facility like the one provided by the CONNECT method in HTTP, and also assuming the existence of a DTLS-TLS transparent mapping, the two tunneled ends should be speaking the same application protocol, which is not the case. Basically, the protocol translation function is a core duty of the cross proxy that can't be removed, and makes it a necessarily trusted, impossible to bypass, component in the communication path.
A reverse proxy deployed at the boundary of a constrained network is an easy single point of failure for reducing availability. As such, a special care should be taken in designing, developing and operating it, keeping in mind that, in most cases, it could have fewer limitations than the constrained devices it is serving.
The following sub paragraphs categorize and argue about a set of specific security issues related to the translation, caching and forwarding functionality exposed by a cross proxy module.
Due to the typically constrained nature of CoAP nodes, particular attention SHOULD be posed in the implementation of traffic reduction mechanisms (see Section 5.3), because inefficient implementations can be targeted by unconstrained Internet attackers. Bandwidth or complexity involved in such attacks is very low.
An amplification attack to the constrained network may be triggered by a multicast request generated by a single HTTP request mapped to a CoAP multicast resource, as considered in Section XX of [I-D.ietf-core-coap].
The impact of this amplification technique is higher than an amplification attack carried out by a malicious constrained device (i.e. ICMPv6 flooding, like Packet Too Big, or Parameter Problem on a multicast destination [RFC4732]), since it does not require direct access to the constrained network.
The feasibility of this attack, disruptive in terms of CoAP server availability, can be limited by access controlling the exposed HTTP multicast resource, so that only known/authorized users access such URIs.
It is possible that the request from the client to the cross proxy is sent over a secured connection. However, there may or may not exist a secure connection mapping to the other protocol. For example, a secure distribution method for multicast traffic is complex and MAY not be implemented (see [I-D.ietf-core-groupcomm]).
By default, a cross proxy SHOULD reject any secured client request if there is no configured security policy mapping. This recommendation MAY be relaxed in case the destination network is believed to be secured by other, complementary, means. E.g.: assumed that CoAP nodes are isolated behind a firewall (e.g. as the SS cross proxy deployment shown in Figure 1), the cross proxy may be configured to translate the incoming HTTPS request using plain CoAP (i.e. NoSec mode.)
The HC URI mapping MUST NOT map to HTTP (see Section 4) a CoAP resource intended to be accessed only using HTTPS.
A secured connection that is terminated at the cross proxy, i.e. the proxy decrypts secured data locally, raises an ambiguity about the cacheability of the requested resource. The cross proxy SHOULD NOT cache any secured content to avoid any leak of secured information. However in some specific scenario, a security/efficiency trade-off could motivate caching secured information; in that case the caching behavior MAY be tuned to some extent on a per-resource basis.
In web security jargon, the "cache poisoning" verb accounts for attacks where an evil user causes the proxy server to associate incorrect content to a cached resource, which work through especially crafted HTTP requests or request/response combos.
When working in CoAP NoSec mode, the use of UDP makes cache poisoning on the constrained network easy and effective, simple address spoofing by a malicious host is sufficient to perform the attack. The implicit broadcast nature of typical link-layer communication technologies used in constrained networks lead this attack to be easily performed by any host, even without the requirement of being a router in the network. The ultimate outcome depends on both the order of arrival of packets (legitimate and rogue) and the processing/discarding policy at the CoAP node; attackers targeting this weakness may have less requirements on timing, thus leading the attack to succeed with high probability.
In case the threat of a rogue mote acting in the constrained network can't be winded up by appropriate procedural means, the only way to avoid such attacks is for any CoAP server to work at least in MultiKey mode with a 1:1 key with the cross proxy. SharedKey mode would just mitigate the attack, since a guessable MIDs and Tokens generation function at the cross proxy side would make it feasible for the evil mote to implement a "try until succeed" strategy. Also, (authenticated) encryption at a lower layer (MAC/PHY) could be defeated by a slightly more powerful attacker, a compromised router mote.
Special credit is given to Klaus Hartke who provided the text for Section 6 and a lot of direct input to this document. Special credit about the text in Section 6 is given to Carsten Bormann who provied parts of it.
Thanks to Zach Shelby, Michele Rossi, Nicola Bui, Michele Zorzi, Peter Saint-Andre, Cullen Jennings, Kepeng Li, Brian Frank, Peter Van Der Stok, Kerry Lynn, Linyi Tian, Dorothy Gellert for helpful comments and discussions that have shaped the document.
The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007-2013] under grant agreement n. [251557].
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. |
| [I-D.ietf-core-coap] | Shelby, Z, Hartke, K, Bormann, C and B Frank, "Constrained Application Protocol (CoAP)", Internet-Draft draft-ietf-core-coap-10, June 2012. |
| [I-D.ietf-core-observe] | Hartke, K, "Observing Resources in CoAP", Internet-Draft draft-ietf-core-observe-05, March 2012. |
| [I-D.ietf-core-block] | Bormann, C and Z Shelby, "Blockwise transfers in CoAP", Internet-Draft draft-ietf-core-block-08, February 2012. |
| [I-D.ietf-core-groupcomm] | Rahman, A and E Dijk, "Group Communication for CoAP", Internet-Draft draft-ietf-core-groupcomm-01, March 2012. |
| [I-D.ietf-httpbis-p1-messaging] | Fielding, R, Lafon, Y and J Reschke, "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Internet-Draft draft-ietf-httpbis-p1-messaging-19, March 2012. |
| [RFC3040] | Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001. |
| [RFC4732] | Handley, M., Rescorla, E., IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006. |
| [I-D.vanderstok-core-bc] | Stok, P and K Lynn, "CoAP Utilization for Building Control", Internet-Draft draft-vanderstok-core-bc-05, October 2011. |
| [I-D.bormann-core-simple-server-discovery] | Bormann, C, "CoRE Simple Server Discovery", Internet-Draft draft-bormann-core-simple-server-discovery-01, March 2012. |
| [I-D.shelby-core-resource-directory] | Shelby, Z and S Krco, "CoRE Resource Directory", Internet-Draft draft-shelby-core-resource-directory-03, May 2012. |