Best Practices for HTTP-CoAP Mapping Implementation
draft-castellani-core-http-mapping-05
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) | ||
| Formats | |||
| 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) |
draft-castellani-core-http-mapping-05
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
KoanLogic
E. Dijk
Philips Research
July 4, 2012
Best Practices for HTTP-CoAP Mapping Implementation
draft-castellani-core-http-mapping-05
Abstract
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 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 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
(http://trustee.ietf.org/license-info) 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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
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:
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
Configuration).
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
Configuration).
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://node.coap.something.net/foo". A possible URI mapping could
Castellani, et al. Expires January 5, 2013 [Page 4]
Internet-Draft HTTP-CoAP Mapping July 2012
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.
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 "//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.
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://node.coap.something.net/foo" can
be accessed at
"http://hc-proxy.something.net/coap/node.coap.something.net/foo".
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
[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.
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
following:
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
clients.
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
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.
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
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.
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
already.
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
translation.
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/
octet-stream".
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
[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.
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
[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.
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
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.
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
mote.
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
[I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
draft-ietf-core-block-08 (work in progress),
February 2012.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-10 (work in progress), June 2012.
[I-D.ietf-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-ietf-core-groupcomm-01 (work in progress),
March 2012.
[I-D.ietf-core-observe]
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.
[I-D.ietf-httpbis-p1-messaging]
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
[I-D.bormann-core-simple-server-discovery]
Bormann, C., "CoRE Simple Server Discovery",
draft-bormann-core-simple-server-discovery-01 (work in
progress), March 2012.
[I-D.shelby-core-resource-directory]
Shelby, Z. and S. Krco, "CoRE Resource Directory",
draft-shelby-core-resource-directory-03 (work in
progress), May 2012.
[I-D.vanderstok-core-bc]
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
Italy
Email: angelo@castellani.net
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Akbar Rahman
InterDigital Communications, LLC
1000 Sherbrooke Street West
Montreal H3A 3G4
canada
Phone: +1 514 585 0761
Email: Akbar.Rahman@InterDigital.com
Thomas Fossati
KoanLogic
Via di Sabbiuno 11/5
Bologna 40136
Italy
Phone: +39 051 644 82 68
Email: tho@koanlogic.com
Esko Dijk
Philips Research
Email: esko.dijk@philips.com
Castellani, et al. Expires January 5, 2013 [Page 17]