Internet DRAFT - draft-jimenez-p2psip-coap-reload
draft-jimenez-p2psip-coap-reload
P2PSIP J. Jimenez
Internet-Draft Ericsson
Intended status: Standards Track J. Lopez-Vega
Expires: January 24, 2016 University of Granada
J. Maenpaa
G. Camarillo
Ericsson
July 23, 2015
A Constrained Application Protocol (CoAP) Usage for REsource LOcation
And Discovery (RELOAD)
draft-jimenez-p2psip-coap-reload-10
Abstract
This document defines a Constrained Application Protocol (CoAP) Usage
for REsource LOcation And Discovery (RELOAD). The CoAP Usage
provides the functionality to federate Wireless Sensor Networks (WSN)
in a peer-to-peer fashion. The CoAP Usage for RELOAD allows CoAP
nodes to store resources in a RELOAD peer-to-peer overlay, provides a
lookup service, and enables the use of RELOAD overlay as a cache for
sensor data. This functionality is implemented in the RELOAD overlay
itself, without the use of centralized servers. The RELOAD AppAttach
method is used to establish a direct connection between nodes through
which CoAP messages are exchanged.
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 24, 2016.
Jimenez, et al. Expires January 24, 2016 [Page 1]
Internet-Draft A CoAP Usage for RELOAD July 2015
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Registering CoAP URIs . . . . . . . . . . . . . . . . . . . . 7
5. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Forming a Direct Connection and Reading Data . . . . . . . . 9
7. Caching Mechanisms . . . . . . . . . . . . . . . . . . . . . 11
7.1. ProxyCache . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. SensorCache . . . . . . . . . . . . . . . . . . . . . . . 12
8. CoAP Usage Kinds Definition . . . . . . . . . . . . . . . . . 14
8.1. CoAP-REGISTRATION Kind . . . . . . . . . . . . . . . . . 14
8.2. CoAP-CACHING Kind . . . . . . . . . . . . . . . . . . . . 14
9. Access Control Rules . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11.1. CoAP-REGISTRATION Kind-ID . . . . . . . . . . . . . . . 16
11.2. CoAP-CACHING Kind-ID . . . . . . . . . . . . . . . . . . 17
11.3. Access Control Policies . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
The CoAP Usage for RELOAD allows CoAP nodes to store resources in a
RELOAD peer-to-peer overlay, provides a lookup service, and enables
the use of RELOAD overlay as a cache for sensor data. This
functionality is implemented in the RELOAD overlay itself, without
the use of centralized servers.
Jimenez, et al. Expires January 24, 2016 [Page 2]
Internet-Draft A CoAP Usage for RELOAD July 2015
This usage is intended for interconnected devices over a wide-area
geographical coverage, such as in cases where multiple Wireless
Sensor Networks (WSN) need to be federated over some wider-area
network. These WSNs would interconnect by means of nodes that are
equipped with long range modules (e.g., 2G, 3G, 4G) as well as short
range ones (e.g., XBee, ZigBee, BLE).
Constrained devices are likely to be heterogeneous when it comes to
their radio layer, however we expect them to use a common application
layer protocol, CoAP. The Constrained Application Protocol (CoAP) is
a specialized web transfer protocol [RFC7252]. It realizes the
Representational State Transfer (REST) architecture for the most
constrained nodes, such as sensors and actuators. CoAP can be used
not only between nodes on the same constrained network but also
between constrained nodes and nodes on the Internet. The latter is
possible since CoAP can be translated to Hypertext Transfer Protocol
(HTTP) for integration with the web. Application areas of CoAP
include different forms of M2M communication, such as home
automation, construction, health care or transportation. Areas with
heavy use of sensor and actuator devices that monitor and interact
with the surrounding environment.
As specified in [RFC6940] RELOAD is fundamentally an overlay network.
Providing a layered architecture with pluggable application layers
than can use the underlaying forwarding, storage and lookup
functionalities. Figure 1 illustrates where the CoAP Usage is placed
within the RELOAD architecture.
Jimenez, et al. Expires January 24, 2016 [Page 3]
Internet-Draft A CoAP Usage for RELOAD July 2015
Application
+-------+
| CoAP | ...
| Usage |
+-------+
------------------------------------ Messaging Service
+------------------+ +---------+
| Message |<--->| Storage |
| Transport | +---------+
+------------------+ ^
^ ^ |
| v v
| +-------------------+
| | Topology |
| | Plug-in |
| +-------------------+
| ^
v v
+------------------+
| Forwarding & |
| Link Management |
+------------------+
------------------------------------ Overlay Link Service
+-------+ +-------+
|TLS | |DTLS | ...
|Overlay| |Overlay|
|Link | |Link |
+-------+ +-------+
Figure 1: Architecture
The CoAP Usage involves three basic functions:
Registration: CoAP nodes that can use the RELOAD data storage
functionality, can store a mapping from their CoAP URI to their Node-
ID in the overlay. They can also retrieve the Node-IDs of other
nodes. Nodes that are not RELOAD aware can use other mechanisms, for
example [I-D.ietf-core-resource-directory] in their local network.
Lookup: Once a CoAP node has identified the Node-ID for an URI it
wishes to retrieve, it can use the RELOAD message routing system to
set up a connection which can be used to exchange CoAP messages.
Similarly as with the registration, nodes that are not RELOAD aware
can use CoAP messages with an Reload Node (RN) that will in turn
perform the lookup in the overlay.
Jimenez, et al. Expires January 24, 2016 [Page 4]
Internet-Draft A CoAP Usage for RELOAD July 2015
Caching: Nodes can use the RELOAD overlay as a caching mechanism for
information about what CoAP resources are available on the node.
This is specially useful for battery constrained nodes that can make
their data available in the cache provided by the overlay while in
sleep mode.
For instance, a CoAP proxy (See Section 3) could register its Node-ID
(e.g. "9996172") and a list of sensors (e.g. "/sensors/temp-1;
/sensors/temp-2; /sensors/light, /sensors/humidity") under its URI
(e.g. "coap://overlay-1.com/proxy-1/").
When a node wants to discover the values associated with that URI, it
queries the overlay for "coap://overlay-1.com/proxy-1/" and gets back
the Node-ID of the proxy and the list of its associated sensors. The
requesting node can then use the RELOAD overlay to establish a direct
connection with the proxy and to read sensor values.
Moreover, the CoAP proxy can store the sensor information in the
overlay. In this way information can be retrieved directly from the
overlay without performing a direct connection to the storing proxy.
2. Terminology
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 RFC 2119 [RFC2119].
We use the terminology and definitions from the RELOAD Base Protocol
[RFC6940] extensively in this document. Some of those concepts are
further described in the Concepts and Terminology for Peer to Peer
SIP [I-D.ietf-p2psip-concepts] document.
3. Architecture
In our architecture we extend the different nodes present in RELOAD
(Peer, Client) and add support for sensor devices or other
constrained devices. Figure 2 illustrates the overlay topology. The
different nodes, according to their functionality are :
Client
As specified in [RFC6940] clients are nodes that do not have
routing or storage responsibilities in the Overlay.
Peer
As specified in [RFC6940] peers are nodes in the overlay that can
route messages for nodes other than those to which it is directly
connected.
Jimenez, et al. Expires January 24, 2016 [Page 5]
Internet-Draft A CoAP Usage for RELOAD July 2015
Sensor
Devices capable of measuring a physical quantity. Sensors usually
acquire quantifiable information about their surrounding
environment such as: temperature, humidity, electric current,
moisture, radiation, and so on.
Actuator
Devices capable of interacting and affecting their environment
such as: electrical motors, pneumatic actuators, electric
switches, and so on.
Proxy Node
Devices having sufficient resources to run RELOAD either as client
or peer. These devices are located at the edge of the sensor
network and, in case of Wireless Sensor Networks (WSN), act as
coordinators of the network.
Physical devices can have one or several of the previous functional
roles. According to the functionalities that are present in each of
the nodes, they can be:
Constrained Node
A Constrained Node (CN) is a node with limited computational
capabilities. CN devices belong to classes of at least C1 and C2
devices as defined in [RFC7228], their main constraint being the
implementation of the CoAP protocol. If the CN is wireless then
it will be part of a Low-Rate Wireless Personal Area Network (LR-
WPAN), also termed Low-Power and Lossy Network (LLN). Lastly,
devices will usually be in sleep mode in order to prevent battery
drain, and will not communicate during those periods. A CN is NOT
part of the RELOAD overlay, therefore it can not act as a client,
peer nor proxy. A CN is always either a either a Sensor or an
Actuator. In the latter case the node is often connected to a
continuous energy power supply.
RELOAD Node
A Reload Node (RN) MUST implement the client functionality in the
Overlay. Additionally the node will often be a full RELOAD peer.
A RN may also be sensor or actuator since it can have those
devices connected to it.
Proxy Node
A Proxy Node (PN) MUST implement the RN functionality and act as a
sink for the LR-WPAN network. The PN connects the short range
Wireless Network to the Wide Area Network or the Internet. A
Proxy Node fulfills the "Proxy Node" role as described above in
the Architecture.
Jimenez, et al. Expires January 24, 2016 [Page 6]
Internet-Draft A CoAP Usage for RELOAD July 2015
+------+
| |
+--------+ RN +---------+
| | | |
+---+--+ +------+ +--+---+
| | | |
| RN | | RN |
| | | | +------------+
+---+--+ +--+---+ | WSN |
| RELOAD | | +----+ |
| OVERLAY | | +---+ CN | |
+---+--+ +--+---+ | | +----+ |
| | | +-----+ |
| RN | | PN | | |
| | | +-----+ |
+---+--+ +------+ +--+---+ | | +----+ |
| | | | | +---+ CN | |
+--------+ PN +---------+ | +----+ |
| | +------------+
+-+--+-+
| |
+--------|--|--------+
| +--+ +--+ |
| | | |
| +--+-+ +-+--+ |
| | CN | | CN | |
| +----+ +----+ |
| WSN |
+--------------------+
Figure 2: Overlay Topology
4. Registering CoAP URIs
CoAP URIs are typically resolved using a DNS. When CoAP is needed in
a RELOAD environment, URI resolution is provided by the overlay as a
whole. Instead of registering a URI, a peer stores a
CoAPRegistration structure under a hash of its own URI. This uses
the CoAP REGISTRATION Kind-ID, which is formally defined in
Section 6, and that uses a DICTIONARY data model.
As an example, if a CoAP proxy that is located in an overlay overlay-
1.com using a Node-ID "9996172" wants to register four different
sensors to the URI "coap://overlay-1.com/proxy-1/.well-known/". We
will be using the link format specified in [RFC6690] to store the
following mapping in the overlay:
Jimenez, et al. Expires January 24, 2016 [Page 7]
Internet-Draft A CoAP Usage for RELOAD July 2015
Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/)
KEY = 9996172,
VALUE = [
</sensors/temp-1>;rt="temperature-c";if="sensor",
</sensors/temp-2>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor",
</sensors/humidity>;rt="humidity-p";if="sensor"
]
Note that the Resource-ID stored in the overlay is calculated as hash
over the URI (i.e. h(URI)), which in RELOAD usually is SHA-1.
This would inform any other node performing a lookup for the previous
URI "coap://overlay-1.com/proxy-1/.well-known" that the Node-ID value
for proxy-1 is "9996172". In addition, this mapping provides
relevant information as to the number of sensors (CNs) and the URI
path to connect to them using CoAP.
5. Lookup
The RELOAD overlay supports a rendezvous system that can be used for
the lookup of other CoAP nodes. This is done by fetching mapping
information between CoAP URIs and Node-IDs.
As an example, if a node RN located in the overlay overlay-1.com
wishes to read which resources are served at a RN with URI
coap://overlay-1.com/proxy-1/, it performs a fetch in the overlay.
The Resource-ID used in this fetch is a SHA-1 hash over the URI
"coap://overlay-1.com/proxy-1/.well-known/".
After this fetch request, the overlay will return the following
result:
Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/)
KEY = 9996172,
VALUE = [
</sensors/temp-1>;rt="temperature-c";if="sensor",
</sensors/temp-2>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor",
</sensors/humidity>;rt="humidity-p";if="sensor"
]
The obtained KEY is the Node-ID of the RN responsible of this KEY/
VALUE pair. The VALUE is the set of URIs necessary to read data from
the CNs associated with the RN.
Jimenez, et al. Expires January 24, 2016 [Page 8]
Internet-Draft A CoAP Usage for RELOAD July 2015
Using the RELOAD DICTIONARY model allows for multiple nodes to
perform a store to the same Resource-ID. This can be used, for
example, to perform a store of resources of the same type or with
similar characteristics. After performing a lookup, this feature
allows to fetch those multiple RNs that host CNs of the same class.
As an example, providing that the previous peer (9996172) and another
peer (9996173) have stored the links to their respective temperature
resources in this same Resource-ID (temperature), a RN (e.g., node-A)
can do a fetch to the URI "coap://overlay-1.com/temperature/.well-
known/", obtaining the following results:
Resource-ID = h(coap://overlay-1.com/temperature/.well-known/)
KEY = 9996172,
VALUE = [
</sensors/temp-1>;rt="temperature-c";if="sensor",
</sensors/temp-2>;rt="temperature-c";if="sensor",
]
KEY = 9996173,
VALUE = [
</sensors/temp-a>;rt="temperature-c";if="sensor",
</sensors/temp-b>;rt="temperature-c";if="sensor"
]
6. Forming a Direct Connection and Reading Data
Once a RN (e.g., node-A) has obtained the lookup information for a
node in the overlay (e.g., proxy-1), it can directly connect to that
node. This is performed by sending an AppAttach request to the Node-
ID obtained during the lookup process.
After the AppAttach negotiation, node-A can access to the values of
the CNs at proxy-1 using the information obtained during the lookup.
Following the example in Section 5, and according to [RFC6690], the
requests for accessing to the CNs at proxy-1 would be:
REQ: GET /sensors/temp-1
REQ: GET /sensors/temp-2
Figure 3 shows a sample of a node reading temperature data.
Jimenez, et al. Expires January 24, 2016 [Page 9]
Internet-Draft A CoAP Usage for RELOAD July 2015
+-----+ +---------+ +-----+ +---+
| PNA | | OVERLAY | | PNB | |CNB|
+-----+ +---------+ +-----+ +---+
| | | |
| | | |
| 1.RELOAD | | |
| FetchReq | | |
|+----------->| | |
| | | |
| 2.RELOAD | | |
| FetchAns | | |
|<-----------+| | |
| | | |
| 3.RELOAD | | |
| AppAttach | | |
|+----------->| | |
| | 4.RELOAD | |
| | AppAttach | |
| |+---------->| |
| | | |
| | 5.RELOAD | |
| 6.RELOAD |AppAttachAns| |
|AppAttachAns |<----------+| |
|<-----------+| | |
| | | |
| | |
| --------------------- | |
| / 7.ICE \| |
| \ connectivity checks /| |
| --------------------- | |
| | |
| 8.CoAP CON | |
| GET /sensors/temp-1 | |
|+------------------------>| |
| | 9.CoAP GET |
| |/sensors/temp-1 |
| |+-------------->|
| | 10.CoAP |
| 11.CoAP | ACK 200 |
| ACK 200 |<--------------+|
|<------------------------+| |
| | |
Figure 3: An Example of a Message Sequence
Jimenez, et al. Expires January 24, 2016 [Page 10]
Internet-Draft A CoAP Usage for RELOAD July 2015
7. Caching Mechanisms
The CoAP protocol itself supports the caching of sensor information
in order to reduce the response time and network bandwidth
consumption of future, equivalent requests. CoAP caching is
specified in the Section 5 of the CoAP RFC [RFC7252], it consists on
reusing stored responses when new requests arrives. This type of
storage is done in CoAP proxies.
This CoAP usage for RELOAD proposes an additional caching mechanism
for storing sensor information directly in the overlay. In order to
do so, it is necessary to define how the data should be stored. Such
caching mechanism is primarily intended for CNs with sensor
capabilities, not for RN sensors. This is due to the battery
constrains of CNs, forcing them to stay in sleep mode for long
periods of time.
Whenever a CN wakes up, it sends the most recent data from its
sensors to its proxy (PN), which stores the data in the overlay using
a RELOAD StoredData structure defined in Section 6 of the RELOAD RFC
[RFC6940]. We use the StoredDataValue structure defined in
Section 6.2 of the RELOAD RFC, in particular we use the SingleValue
format type to store the cached values in the overlay. From that
structure length, storage_time, lifetime and Signature are used in
the same way. The only difference is DataValue which in our case can
be either a ProxyCache or a SensorCache:
enum { reserved (0), proxy_cache(1), sensor_cache(2), (255) }
CoAPCachingType;
struct {
CoAPCachingType coap_caching_type;
select(coap_caching_type) {
case proxy_cache: ProxyCache proxy_cache_entry;
case sensor_cache: SensorCache sensor_cache_entry;
/* extensions */
}
} CoAPCaching;
7.1. ProxyCache
ProxyCache is meant to store values and sensor information (e.g.
inactivity time) for all the sensors associated with a certain proxy,
as well as their CoAP URIs. On the other hand, SensorCache is used
for storing the information and cached value of only one sensor (CoAP
URI is not necessary, as is the same as the one used for generating
the Resource-ID associated to that SensorCache entry).
Jimenez, et al. Expires January 24, 2016 [Page 11]
Internet-Draft A CoAP Usage for RELOAD July 2015
ProxyCache contains the fields Node-ID and series of SensorEntry
types.
struct {
Node-ID Node_ID;
uint32 length;
SensorEntry sensors[count];
} ProxyCache;
Node-D
The Node-ID of the Proxy Node (PN) responsible for different
sensor devices;
length
The length of the rest of the structure;
Sensor-Entry
List of sensors in the form of SensorEntry types;
SensorEntry contains the coap_uri, sensor_info and a series of
SensorValue types.
struct {
opaque coap_uri;
SensorInfo sensor_info;
uint32 length;
SensorValue sensor_value[count];
} SensorEntry;
coap_uri
CoAP name of the sensor device in question;
sensor_info
contains relevant sensor information;
length
The length of the rest of the structure;
sensor_value
contains a list of values stored by the sensor;
7.2. SensorCache
SensorCache: contains the information related to one sensor.
Jimenez, et al. Expires January 24, 2016 [Page 12]
Internet-Draft A CoAP Usage for RELOAD July 2015
struct {
Node-ID Node_ID;
SensorInfo sensor_info;
uint32 length;
SensorValue sensor_value[count];
} SensorCache;
Node_ID
identifies the Node-ID of the Proxy Node responsible for the
sensor;
sensor_info
contains relevant sensor information;
length
The length of the rest of the structure;
sensor_value
contains a list of values stored by the sensor;
SensorInfo contains relevant sensor information that is dependent on
the use case. As an example we use the sensor manufacturer as
relevant information.
struct {
opaque dev_info;
/* extensions */
} SensorInfo;
dev_info
Contains specific device information as defined in [RFC6690], for
example temperature, luminosity, etc. It can also represent other
semantic information about the device.
SensorValue contains the measurement_time, lifetime and value of the
measurement.
struct {
uint32 measurement_time;
uint32 lifetime;
opaque value;
/* extensions */
} SensorValue;
Jimenez, et al. Expires January 24, 2016 [Page 13]
Internet-Draft A CoAP Usage for RELOAD July 2015
measurement_time
indicates the moment in which the measure was taken represented as
the number of milliseconds elapsed since midnight Jan 1, 1970 UTC
not counting leap seconds;
lifetime
indicates the validity time of that measured value in milliseconds
since measurement_time;
value
indicates the actual value measured. It can be of different types
(integer, long, string) therefore opaque has been used;
8. CoAP Usage Kinds Definition
This section defines the CoAP-REGISTRATION and CoAP-CACHING kinds.
8.1. CoAP-REGISTRATION Kind
Kind IDs
The Resource Name for the CoAP-REGISTRATION Kind-ID is the CoAP
URI. The data stored is a CoAPRegistration, which contains a set
of CoAP URIs.
Data Model
The data model for the CoAP-REGISTRATION Kind-ID is dictionary.
The dictionary key is the Node-ID of the storing RN. This allows
each RN to store a single mapping.
Access Control
URI-NODE-MATCH. The "coap:" prefix needs to be removed from the
COAP URI before matching.
Data stored under the COAP-REGISTRATION kind is of type
CoAPRegistration, defined below.
struct {
Node-ID Node_ID;
uint16 coap_uris_length;
opaque coap_uris (0..2^16-1);
} CoAPRegistration;
8.2. CoAP-CACHING Kind
KindIDs
The Resource Name for the CoAP-CACHING Kind-ID is the CoAP URI.
The data stored is a CoAPCaching, which contains a cached value.
Jimenez, et al. Expires January 24, 2016 [Page 14]
Internet-Draft A CoAP Usage for RELOAD July 2015
Data Model
The data model for the CoAP-CACHING Kind-ID is single value.
Access Control
URI-MATCH. The "coap:" prefix needs to be removed from the COAP
URI before matching.
Data stored under the CoAP-CACHING kind is of type CoAPCaching,
defined in Section 7.
9. Access Control Rules
As specified in RELOAD base [RFC6940], every kind which is storable
in an overlay must be associated with an access control policy. This
policy defines whether a request from a given node to operate on a
given value should succeed or fail. Usages can define any access
control rules they choose, including publicly writable values.
CoAP Usage for RELOAD requires an access control policy that allows
multiple nodes in the overlay read and write access. This access is
for registering and caching information using CoAP URIs as
identifiers. Therefore, none of the access control policies
specified in RELOAD base are sufficient.
This document defines two access control policies, called URI-MATCH
and URI-NODE-MATCH. In URI-MATCH policy, a given value MUST be
written and overwritten if and only if the signer's certificate
contains an uniformResourceIdentifier entry in the subjectAltName
Extension [RFC5280] that in canonicalized form hashes to the
Resource-ID for the resource. As explained on Section 6.3 of the
COAP RFC [RFC7252] the "coap" and "coaps" schemes conform to the
generic URI, thus they are normalized in the generic form as
explained on Section 6 of [RFC3986]. The hash function used is
specified in Section 10.2 of [RFC6940]. The certificate can be
generated as specified on Section 9 of the COAP RFC [RFC7252],
Certificate Option.
In URI-NODE-MATCH policy, a given value MUST be written and
overwritten if and only if the condition for URI-MATCH is met and, in
addition, the dictionary key is equal to the Node-ID in the
certificate and that Node-ID is the one indicated in the
SignerIdentity value cert_hash.
These Access Control Policies are specified for IANA in
Section Section 11.3.
Jimenez, et al. Expires January 24, 2016 [Page 15]
Internet-Draft A CoAP Usage for RELOAD July 2015
10. Security Considerations
The security considerations of RELOAD [RFC6940] and CoAP [RFC7252]
apply to this specification. RELOAD's security model is based on
public key certificates, which are used for signing messages and
stored objects. At the connection level RELOAD can use either TLS or
DTLS. In the case of CoAP, several security modes have been defined.
Implementations of this specification MUST follow all the security-
related rules specified in the RELOAD [RFC6940] and CoAP [RFC7252]
specifications.
Additionally, in RELOAD every kind which is storable in an overlay
must be associated with an access control policy. This document
specifies two new access control policies, which are specified in
Section 9. These policies cover the most typical deployment
scenarios.
During the phase of registration and lookup, security considerations
relevant to RELOAD apply. A CoAP node that advertises it's existence
via this mechanism, is more likely to be attacked, compared to a node
(especially a sleepy node) that does not advertise it's existence.
Section 11 of [RFC7252] and Section 13 of [RFC6940] have more
information on the kinds of attack and mitigation possible.
The caching mechanism specified in this draft is additional to the
caching already done in CoAP. Access control is handled by the
RELOAD overlay, where the peer storing the data is responsible of
validating the signature on the data being stored.
11. IANA Considerations
11.1. CoAP-REGISTRATION Kind-ID
This document introduces one additional data Kind-ID to the "RELOAD
Data Kind-ID" Registry:
+-------------------+------------+----------+
| Kind | Kind-ID | RFC |
+-------------------+------------+----------+
| CoAP-REGISTRATION | 105 | RFC-AAAA |
+-------------------+------------+----------+
This Kind-ID was defined in Section 4.
Jimenez, et al. Expires January 24, 2016 [Page 16]
Internet-Draft A CoAP Usage for RELOAD July 2015
11.2. CoAP-CACHING Kind-ID
This document introduces one additional data Kind-ID to the "RELOAD
Data Kind-ID" Registry:
+--------------+------------+----------+
| Kind | Kind-ID | RFC |
+--------------+------------+----------+
| CoAP-CACHING | 106 | RFC-AAAA |
+--------------+------------+----------+
This Kind-ID was defined in Section 4.
11.3. Access Control Policies
IANA is asked to create a "CoAP Usage for RELOAD Access Control
Policy" Registry. This registry is to be added to the existing
RELOAD registry. Entries in this registry are strings denoting
access control policies, as described in Section 8.1. New entries in
this registry are to be registered per the Specification Required
policy in [RFC5226]. The initial contents of this registry are:
+-----------------+----------+
| Access Policy | RFC |
+-----------------+----------+
| URI-NODE-MATCH | RFC-AAAA |
| URI-MATCH | RFC-AAAA |
+-----------------+----------+
This access control policy was described in Section 9.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
Jimenez, et al. Expires January 24, 2016 [Page 17]
Internet-Draft A CoAP Usage for RELOAD July 2015
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012.
[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", RFC 6940, January 2014.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
12.2. Informative References
[I-D.ietf-core-resource-directory]
Shelby, Z. and C. Bormann, "CoRE Resource Directory",
draft-ietf-core-resource-directory-02 (work in progress),
November 2014.
[I-D.ietf-p2psip-concepts]
Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-06 (work in progress), June
2014.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014.
Authors' Addresses
Jaime Jimenez
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: jaime.jimenez@ericsson.com
Jose M. Lopez-Vega
University of Granada
CITIC UGR Periodista Rafael Gomez Montero 2
Granada 18071
Spain
Email: jmlvega@ugr.es
Jimenez, et al. Expires January 24, 2016 [Page 18]
Internet-Draft A CoAP Usage for RELOAD July 2015
Jouni Maenpaa
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: jouni.maenpaa@ericsson.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: gonzalo.camarillo@ericsson.com
Jimenez, et al. Expires January 24, 2016 [Page 19]
