Skip to main content

Best Practices for HTTP-CoAP Mapping Implementation

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Angelo P. Castellani , Salvatore Loreto , Akbar Rahman , Thomas Fossati , Esko Dijk
Last updated 2012-07-04
Replaced by draft-ietf-core-http-mapping, draft-ietf-core-http-mapping, RFC 8075
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
CoRE Working Group                                         A. Castellani
Internet-Draft                                      University of Padova
Intended status: Informational                                 S. Loreto
Expires: January 5, 2013                                        Ericsson
                                                               A. Rahman
                                        InterDigital Communications, LLC
                                                              T. Fossati
                                                                 E. Dijk
                                                        Philips Research
                                                            July 4, 2012

          Best Practices for HTTP-CoAP Mapping Implementation


   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.

Status of this Memo

   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

   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 5, 2013.

Copyright Notice

   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
   ( in effect on the date of

Castellani, et al.       Expires January 5, 2013                [Page 1]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Cross-Protocol Usage of URIs . . . . . . . . . . . . . . . . .  4
   4.  URI Mapping  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Homogeneous Mapping  . . . . . . . . . . . . . . . . . . .  5
     4.2.  Embedded Mapping . . . . . . . . . . . . . . . . . . . . .  5
   5.  HTTP-CoAP Implementation . . . . . . . . . . . . . . . . . . .  6
     5.1.  HTTP-CoAP Reverse Cross Proxy  . . . . . . . . . . . . . .  6
     5.2.  Other Placement Aspects  . . . . . . . . . . . . . . . . .  7
     5.3.  Caching and Congestion Control . . . . . . . . . . . . . .  9
     5.4.  Cache Refresh via Observe  . . . . . . . . . . . . . . . .  9
     5.5.  Use of CoAP Blockwise Transfer . . . . . . . . . . . . . . 10
   6.  CoAP-HTTP Implementation . . . . . . . . . . . . . . . . . . . 11
     6.1.  Basic mapping  . . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  Payloads and Media Types . . . . . . . . . . . . . . . . . 11
     6.3.  Max-Age and ETag Options . . . . . . . . . . . . . . . . . 12
     6.4.  Use of CoAP Blockwise Transfer . . . . . . . . . . . . . . 12
     6.5.  HTTP Status Codes 1xx and 3xx  . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
     8.1.  Traffic overflow . . . . . . . . . . . . . . . . . . . . . 13
     8.2.  Handling Secured Exchanges . . . . . . . . . . . . . . . . 14
     8.3.  Spoofing and Cache Poisoning . . . . . . . . . . . . . . . 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Castellani, et al.       Expires January 5, 2013                [Page 2]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

1.  Introduction

   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",
   document are to be interpreted as described in [RFC2119].

2.  Terminology

   Cross-Protocol Proxy (or Cross Proxy): a cross-protocol mapping
   proxy, typically a HTTP-CoAP mapping proxy in the context of this

   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:

   Forward proxy (F):  Is a proxy known by the client (either CoAP or
      HTTP) used to access a specific cross-protocol server
      (respectively HTTP or CoAP).  Main feature: server(s) do not
      require to be known in advance by the proxy (ZSC: Zero Server

   Reverse proxy (R):  Is a proxy known by the client to be the server,
      however for a subset of resources it works as a proxy, by knowing
      the real server(s) serving each resource.  When a cross-protocol
      resource is accessed by a client, the request will be silently
      forwarded by the reverse proxy to the real server (running a
      different protocol).  If a response is received by the reverse
      proxy, it will be mapped, if possible, to the original protocol
      and sent back to the client.  Main feature: client(s) do not
      require to know in advance the proxy (ZCC: Zero Client

Castellani, et al.       Expires January 5, 2013                [Page 3]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

   Interception proxy (I):  This proxy [RFC3040] can intercept any
      origin protocol request (HTTP or CoAP) and map it to the
      destination protocol, without any kind of knowledge about the
      client or server involved in the exchange.  Main feature:
      client(s) and server(s) do not require to know or be known in
      advance by the proxy (ZCC and ZSC).

   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).

3.  Cross-Protocol Usage of URIs

   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.

4.  URI Mapping

   URI Mapping: the act of providing an alternative URI to access a
   target resource.

   Example: Assume that the target resource is
   "coap://".  A possible URI mapping could

Castellani, et al.       Expires January 5, 2013                [Page 4]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

   be "".

   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://".  The resource identified by
   "" 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

   Two static HC URI mappings are discussed in the following

4.1.  Homogeneous Mapping

   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 "//" identified
   either by the URI "coap://", and or by the
   URI "" 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.

4.2.  Embedded Mapping

   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://" can
   be accessed at

Castellani, et al.       Expires January 5, 2013                [Page 5]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

   This mapping technique can be used to reduce the mapping complexity
   in an HTTP-CoAP Reverse Cross Proxy.

5.  HTTP-CoAP Implementation

   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

   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

   HTTP connection pipelining (section 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.

5.1.  HTTP-CoAP Reverse Cross Proxy

   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:

   TCP/UDP:  Translation between HTTP and CoAP requires also a TCP to
      UDP mapping; UDP performance over the unconstrained Internet may
      not be adequate.  In order to minimize the number of required
      retransmissions and overall reliability, TCP/UDP conversion SHOULD

Castellani, et al.       Expires January 5, 2013                [Page 6]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

      be performed at a SS placed proxy.

   Caching:  Efficient caching requires that all the CoAP traffic is
      intercepted by the same proxy, thus an SS placement, collecting
      all the traffic, is strategical for this need.

   Multicast:  To support CoAP using local-multicast functionalities
      available in the constrained network, the cross proxy MAY require
      a network interface directly attached to the constrained network.

                            |      |
                            | DNS  |
                            |      |
                                               /                    \
                                              /  /-----\     /-----\ \
                                             /     CoAP       CoAP    \
                                            /    server      server    \
                                           ||    \-----/     \-----/   ||
                                     +----------+                      ||
                                     | HTTP/CoAP|        /-----\       ||
                                     |  Cross   |          CoAP        ||
                                     |  Proxy   |         server       ||
    +------+                         +----------+        \-----/       ||
    |HTTP  |                               ||   /-----\                ||
    |Client|                               ||    CoAP                  ||
    +------+                                \    server                /
                                             \  \-----/               /
                                              \         /-----\      /
                                               \         CoAP       /
                                                \        server    /
                                                 \      \-----/   /

           Figure 1: Server-side Cross Proxy Deployment Scenario

5.2.  Other Placement Aspects

   Other important aspects involved in the selection of which type of
   proxy deployment, whose choice impacts its placement too, are the

Castellani, et al.       Expires January 5, 2013                [Page 7]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

   Client/Proxy/Network configuration overhead:  Forward proxies require
      either static configuration or discovery support in the client.
      Reverse proxies require either static configuration, server
      discovery or embedded URI mapping in the proxy.  Interception
      proxies require minimal deployment effort (i.e. routing setup of
      web traffic toward the proxy).

   Scalability/Availability:  Both aspects are typically addressed using
      redundancy.  CS deployments, due to the limited catchment area and
      administrative-wide domain of operation, have looser requirements
      on this.  SS deployments, in dense/popular/critical environments,
      have stricter requirements and MAY need to be replicated.
      Stateful proxies (e.g. reverse) may be complex to replicate.

   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            |    - |    - |    + |

               Table 1: Interesting cross proxy deployments

   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

Castellani, et al.       Expires January 5, 2013                [Page 8]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

5.3.  Caching and Congestion Control

   The cross proxy SHOULD limit the number of requests to CoAP servers
   by responding, where applicable, with a cached representation of the

   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

   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.

5.4.  Cache Refresh via Observe

   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,

Castellani, et al.       Expires January 5, 2013                [Page 9]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

   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

   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-

   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.

5.5.  Use of CoAP Blockwise Transfer

   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

Castellani, et al.       Expires January 5, 2013               [Page 10]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

   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

6.  CoAP-HTTP Implementation

   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.

6.1.  Basic mapping

   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

6.2.  Payloads and Media Types

   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/

Castellani, et al.       Expires January 5, 2013               [Page 11]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

6.3.  Max-Age and ETag Options

   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.

6.4.  Use of CoAP Blockwise Transfer

   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

   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.

6.5.  HTTP Status Codes 1xx and 3xx

   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.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   The security concerns raised in Section 15.7 of [RFC2616] also apply

Castellani, et al.       Expires January 5, 2013               [Page 12]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

   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.

8.1.  Traffic overflow

   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

   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

Castellani, et al.       Expires January 5, 2013               [Page 13]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

8.2.  Handling Secured Exchanges

   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

   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.

8.3.  Spoofing and Cache Poisoning

   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

Castellani, et al.       Expires January 5, 2013               [Page 14]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

   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

9.  Acknowledgements

   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].

10.  References

10.1.  Normative References

              Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
              draft-ietf-core-block-08 (work in progress),
              February 2012.

              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-10 (work in progress), June 2012.

              Rahman, A. and E. Dijk, "Group Communication for CoAP",
              draft-ietf-core-groupcomm-01 (work in progress),
              March 2012.


Castellani, et al.       Expires January 5, 2013               [Page 15]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

              Hartke, K., "Observing Resources in CoAP",
              draft-ietf-core-observe-05 (work in progress), March 2012.

              Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part
              1: URIs, Connections, and Message Parsing",
              draft-ietf-httpbis-p1-messaging-19 (work in progress),
              March 2012.

   [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.

10.2.  Informative References

              Bormann, C., "CoRE Simple Server Discovery",
              draft-bormann-core-simple-server-discovery-01 (work in
              progress), March 2012.

              Shelby, Z. and S. Krco, "CoRE Resource Directory",
              draft-shelby-core-resource-directory-03 (work in
              progress), May 2012.

              Stok, P. and K. Lynn, "CoAP Utilization for Building
              Control", draft-vanderstok-core-bc-05 (work in progress),
              October 2011.

   [RFC3040]  Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
              Replication and Caching Taxonomy", RFC 3040, January 2001.

   [RFC4732]  Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
              Service Considerations", RFC 4732, December 2006.

Castellani, et al.       Expires January 5, 2013               [Page 16]
Internet-Draft              HTTP-CoAP Mapping                  July 2012

Authors' Addresses

   Angelo P. Castellani
   University of Padova
   Via Gradenigo 6/B
   Padova  35131


   Salvatore Loreto
   Hirsalantie 11
   Jorvas  02420


   Akbar Rahman
   InterDigital Communications, LLC
   1000 Sherbrooke Street West
   Montreal  H3A 3G4

   Phone: +1 514 585 0761

   Thomas Fossati
   Via di Sabbiuno 11/5
   Bologna  40136

   Phone: +39 051 644 82 68

   Esko Dijk
   Philips Research


Castellani, et al.       Expires January 5, 2013               [Page 17]