< draft-ietf-core-groupcomm-18.txt   draft-ietf-core-groupcomm-19.txt >
CoRE Working Group A. Rahman, Ed. CoRE Working Group A. Rahman, Ed.
Internet-Draft InterDigital Communications, LLC Internet-Draft InterDigital Communications, LLC
Intended status: Informational E. Dijk, Ed. Intended status: Informational E. Dijk, Ed.
Expires: June 26, 2014 Philips Research Expires: December 19, 2014 Philips Research
December 23, 2013 June 17, 2014
Group Communication for CoAP Group Communication for CoAP
draft-ietf-core-groupcomm-18 draft-ietf-core-groupcomm-19
Abstract Abstract
CoAP is a specialized web transfer protocol for constrained devices CoAP is a specialized web transfer protocol for constrained devices
and constrained networks. It is anticipated that constrained devices and constrained networks. It is anticipated that constrained devices
will often naturally operate in groups (e.g., in a building will often naturally operate in groups (e.g., in a building
automation scenario all lights in a given room may need to be automation scenario all lights in a given room may need to be
switched on/off as a group). This document provides guidance for how switched on/off as a group). This document provides guidance for how
the CoAP protocol should be used in a group communication context. the CoAP protocol should be used in a group communication context.
An approach for using CoAP on top of IP multicast is detailed. Also, An approach for using CoAP on top of IP multicast is detailed. Also,
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 26, 2014. This Internet-Draft will expire on December 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Conventions and Terminology . . . . . . . . . . . . . . . 4 1.3. Conventions and Terminology . . . . . . . . . . . . . . . 4
2. Protocol Considerations . . . . . . . . . . . . . . . . . . . 5 2. Protocol Considerations . . . . . . . . . . . . . . . . . . . 5
2.1. IP Multicast Background . . . . . . . . . . . . . . . . . 5 2.1. IP Multicast Background . . . . . . . . . . . . . . . . . 5
2.2. Group Definition and Naming . . . . . . . . . . . . . . . 6 2.2. Group Definition and Naming . . . . . . . . . . . . . . . 6
2.3. Port and URI Configuration . . . . . . . . . . . . . . . 7 2.3. Port and URI Configuration . . . . . . . . . . . . . . . 7
2.4. RESTful Methods . . . . . . . . . . . . . . . . . . . . . 8 2.4. RESTful Methods . . . . . . . . . . . . . . . . . . . . . 8
2.5. Request and Response Model . . . . . . . . . . . . . . . 8 2.5. Request and Response Model . . . . . . . . . . . . . . . 9
2.6. Member Discovery . . . . . . . . . . . . . . . . . . . . 9 2.6. Member Discovery . . . . . . . . . . . . . . . . . . . . 10
2.7. Membership Configuration . . . . . . . . . . . . . . . . 9 2.7. Membership Configuration . . . . . . . . . . . . . . . . 10
2.7.1. Background . . . . . . . . . . . . . . . . . . . . . 9 2.7.1. Background . . . . . . . . . . . . . . . . . . . . . 10
2.7.2. Membership Configuration RESTful Interface . . . . . 10 2.7.2. Membership Configuration RESTful Interface . . . . . 10
2.8. Request Acceptance and Response Suppression Rules . . . . 15 2.8. Request Acceptance and Response Suppression Rules . . . . 15
2.9. Congestion Control . . . . . . . . . . . . . . . . . . . 17 2.9. Congestion Control . . . . . . . . . . . . . . . . . . . 17
2.10. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 18 2.10. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 18
2.11. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 19 2.11. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 20
3. Use Cases and Corresponding Protocol Flows . . . . . . . . . 19 3. Use Cases and Corresponding Protocol Flows . . . . . . . . . 20
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Network Configuration . . . . . . . . . . . . . . . . . . 20 3.2. Network Configuration . . . . . . . . . . . . . . . . . . 20
3.3. Discovery of Resource Directory . . . . . . . . . . . . . 22 3.3. Discovery of Resource Directory . . . . . . . . . . . . . 22
3.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 23 3.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 24
3.5. Lighting Control in MLD Enabled Network . . . . . . . . . 27 3.5. Lighting Control in MLD Enabled Network . . . . . . . . . 28
3.6. Commissioning the Network Based On Resource Directory . . 28 3.6. Commissioning the Network Based On Resource Directory . . 29
4. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 29 4. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 30
4.1. Target Network Topologies . . . . . . . . . . . . . . . . 29 4.1. Target Network Topologies . . . . . . . . . . . . . . . . 30
4.2. Networks Using the MLD Protocol . . . . . . . . . . . . . 30 4.2. Networks Using the MLD Protocol . . . . . . . . . . . . . 31
4.3. Networks Using RPL Multicast Without MLD . . . . . . . . 30 4.3. Networks Using RPL Multicast Without MLD . . . . . . . . 31
4.4. Networks Using MPL Forwarding Without MLD . . . . . . . . 31 4.4. Networks Using MPL Forwarding Without MLD . . . . . . . . 32
4.5. 6LoWPAN Specific Guidelines for the 6LBR . . . . . . . . 32 4.5. 6LoWPAN Specific Guidelines for the 6LBR . . . . . . . . 33
5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
5.1. Security Configuration . . . . . . . . . . . . . . . . . 32 5.1. Security Configuration . . . . . . . . . . . . . . . . . 33
5.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 33 5.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 34
5.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 33 5.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 34
5.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 33 5.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 34
5.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 34 5.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 35
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 5.4. Pervasive Monitoring Considerations . . . . . . . . . . . 35
6.1. New 'core.gp' Resource Type . . . . . . . . . . . . . . . 34
6.2. New 'coap-group+json' Internet Media Type . . . . . . . . 34 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 6.1. New 'core.gp' Resource Type . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.2. New 'coap-group+json' Internet Media Type . . . . . . . . 36
8.1. Normative References . . . . . . . . . . . . . . . . . . 36 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . 37
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 40
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
1.1. Background 1.1. Background
Constrained Application Protocol (CoAP) is a Representational State Constrained Application Protocol (CoAP) is a Representational State
Transfer (REST) based web transfer protocol for resource constrained Transfer (REST) based web transfer protocol for resource constrained
devices operating in an IP network [I-D.ietf-core-coap]. CoAP has devices operating in an IP network [I-D.ietf-core-coap]. CoAP has
many similarities to HTTP [RFC2616] but also has some key many similarities to HTTP [RFC2616] but also has some key
differences. Constrained devices can be large in numbers, but are differences. Constrained devices can be large in numbers, but are
skipping to change at page 4, line 25 skipping to change at page 4, line 25
CoAP group communication. An implementation of CoAP group CoAP group communication. An implementation of CoAP group
communication MAY implement these guidelines; an implementation communication MAY implement these guidelines; an implementation
claiming compliance to this document MUST implement the set of claiming compliance to this document MUST implement the set of
guidelines. guidelines.
This document assumes readers are familiar with the terms and This document assumes readers are familiar with the terms and
concepts that are used in [I-D.ietf-core-coap]. In addition, this concepts that are used in [I-D.ietf-core-coap]. In addition, this
document defines the following terminology: document defines the following terminology:
Group Communication Group Communication
A source node sends a single application layer (e.g. CoAP) message A source node sends a single application layer (e.g. CoAP)
which is delivered to multiple destination nodes, where all message which is delivered to multiple destination nodes, where
destinations are identified to belong to a specific group. The all destinations are identified to belong to a specific group.
source node itself may be part of the group. The underlying The source node itself may be part of the group. The underlying
mechanisms for CoAP group communication are UDP/IP multicast for mechanisms for CoAP group communication are UDP/IP multicast for
the requests, and unicast UDP/IP for the responses. The network the requests, and unicast UDP/IP for the responses. The network
involved may be a constrained network such as a low-power, lossy involved may be a constrained network such as a low-power, lossy
network. network.
Reliable Group Communication Reliable Group Communication
A special case of group communication where for each destination A special case of group communication where for each destination
node it is guaranteed that the node either 1) eventually receives node it is guaranteed that the node either 1) eventually receives
the message sent by the source node, or 2) does not receive the the message sent by the source node, or 2) does not receive the
message and the source node is notified of the non-reception message and the source node is notified of the non-reception
skipping to change at page 6, line 33 skipping to change at page 6, line 33
A CoAP group URI has the scheme 'coap' and includes in the authority A CoAP group URI has the scheme 'coap' and includes in the authority
part either a group IP multicast address, or a hostname (e.g., Group part either a group IP multicast address, or a hostname (e.g., Group
Fully Qualified Domain Name (FQDN)) that can be resolved to the group Fully Qualified Domain Name (FQDN)) that can be resolved to the group
IP multicast address. A group URI also contains an optional CoAP IP multicast address. A group URI also contains an optional CoAP
port number in the authority part. Group URIs follow the regular port number in the authority part. Group URIs follow the regular
CoAP URI syntax [I-D.ietf-core-coap]. CoAP URI syntax [I-D.ietf-core-coap].
Note: A group URI is needed to initiate CoAP group communications. Note: A group URI is needed to initiate CoAP group communications.
For CoAP implementations it is recommended to use the URI composition For CoAP implementations it is recommended to use the URI composition
method of Section 6.5 of [I-D.ietf-core-coap] in such way that a CoAP method of Section 6.5 of [I-D.ietf-core-coap] in such way that, from
group communication request is generated. a group URI, a CoAP group communication request is generated.
For sending nodes, it is recommended to use the IP multicast address For sending nodes, it is recommended to use the IP multicast address
literal in a group URI. However, in case a group hostname is used, literal in a group URI. However, in case a group hostname is used,
it can be uniquely mapped to an IP multicast address via DNS it can be uniquely mapped to an IP multicast address via DNS
resolution (if supported). Some examples of hierarchical group FQDN resolution (if supported). Some examples of hierarchical group FQDN
naming (and scoping) for a building control application are shown naming (and scoping) for a building control application are shown
below: below:
URI authority Targeted group of nodes URI authority Targeted group of nodes
--------------------------------------- -------------------------- --------------------------------------- --------------------------
skipping to change at page 7, line 29 skipping to change at page 7, line 29
shooting to translate IP multicast addresses back to human readable shooting to translate IP multicast addresses back to human readable
hostnames to show in a diagnostics user interface. hostnames to show in a diagnostics user interface.
2.3. Port and URI Configuration 2.3. Port and URI Configuration
A CoAP server that is a member of a group listens for CoAP messages A CoAP server that is a member of a group listens for CoAP messages
on the group's IP multicast address, on a specified UDP port. The on the group's IP multicast address, on a specified UDP port. The
default UDP port is the CoAP default port 5683 but a non-default UDP default UDP port is the CoAP default port 5683 but a non-default UDP
port MAY be specified for the group; in which case implementers MUST port MAY be specified for the group; in which case implementers MUST
ensure that all group members are configured to use this same port. ensure that all group members are configured to use this same port.
These rules imply that different ports (for the same IP multicast
address) cannot be used to specify different CoAP groups.
CoAP group communication will not work if there is diversity in the CoAP group communication will not work if there is diversity in the
authority port (e.g., different dynamic port addresses across the authority port (e.g., different dynamic port addresses across the
group) or if other parts of the group URI such as the path, or the group) or if other parts of the group URI such as the path, or the
query, differ on different endpoints. Therefore, some measures must query, differ on different endpoints. Therefore, some measures must
be present to ensure uniformity in port number and resource names/ be present to ensure uniformity in port number and resource names/
locations within a group. All CoAP group communication requests MUST locations within a group. All CoAP group communication requests MUST
be sent using a port number according to one of below options: be sent using a port number according to one of below options:
1. A pre-configured port number. The pre-configuration mechanism 1. A pre-configured port number. The pre-configuration mechanism
skipping to change at page 9, line 13 skipping to change at page 9, line 20
[I-D.ietf-core-coap]. [I-D.ietf-core-coap].
A server MAY send back a unicast response to the CoAP group A server MAY send back a unicast response to the CoAP group
communication request (e.g., response "2.05 Content" to a group GET communication request (e.g., response "2.05 Content" to a group GET
request). The unicast responses received by the CoAP client may be a request). The unicast responses received by the CoAP client may be a
mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not
Found) codes depending on the individual server processing results. Found) codes depending on the individual server processing results.
Detailed processing rules for IP multicast request acceptance and Detailed processing rules for IP multicast request acceptance and
unicast response suppression are given in Section 2.8. unicast response suppression are given in Section 2.8.
A CoAP request sent over IP multicast and any unicast response must A CoAP request sent over IP multicast and any unicast response it
take into account the congestion control rules defined in causes must take into account the congestion control rules defined in
Section 2.9. Section 2.9.
The CoAP client can distinguish the origin of multiple server The CoAP client can distinguish the origin of multiple server
responses by source IP address of the UDP message containing the CoAP responses by source IP address of the UDP message containing the CoAP
response, or any other available unique identifier (e.g. contained in response, or any other available unique identifier (e.g. contained in
the CoAP payload). In case a CoAP client sent multiple group the CoAP payload). In case a CoAP client sent multiple group
requests, the responses are as usual matched to a request using the requests, the responses are as usual matched to a request using the
CoAP Token. CoAP Token.
For multicast CoAP requests there are additional constraints on the
re-use of Token values, compared to the unicast case. In the unicast
case, receiving a response effectively frees up its Token value for
re-use since no more responses will follow. However, for multicast
CoAP the number of responses is not bounded a-priori. Therefore the
reception of a response cannot be used as a trigger to "free up" a
Token value for re-use. Re-using a Token value too early could lead
to protocol error i.e. a wrong response/request matching in the
client. Therefore the time between re-use of Token values (for Token
values used in multicast requests) must be at least:
NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPONSE_DELAY
where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of
[I-D.ietf-core-coap]. MAX_SERVER_RESPONSE_DELAY is defined here as
the expected maximum response delay over all servers that the client
can send a multicast request to. This delay includes the maximum
Leisure time period as defined in Section 8.2 of
[I-D.ietf-core-coap]. Using the CoAP default protocol parameters the
re-use time becomes at least 250 seconds, but may need to be much
longer in practice since there is no time limit defined in CoAP for
generation of responses by a server.
2.6. Member Discovery 2.6. Member Discovery
CoAP Groups, and the membership of these groups, can be discovered CoAP Groups, and the membership of these groups, can be discovered
via the lookup interfaces in the Resource Directory (RD) defined in via the lookup interfaces in the Resource Directory (RD) defined in
[I-D.ietf-core-resource-directory]. An example of doing some of [I-D.ietf-core-resource-directory]. An example of doing some of
these RD lookups is given in Section 3.6. these RD lookups is given in Section 3.6.
2.7. Membership Configuration 2.7. Membership Configuration
2.7.1. Background 2.7.1. Background
skipping to change at page 18, line 10 skipping to change at page 18, line 39
is given in Section 5 of [RFC6690]. is given in Section 5 of [RFC6690].
o A server can also minimize the payload length of a response to a o A server can also minimize the payload length of a response to a
group communication GET (e.g., on "/.well-known/core") using CoAP group communication GET (e.g., on "/.well-known/core") using CoAP
blockwise transfers [I-D.ietf-core-block], returning only a first blockwise transfers [I-D.ietf-core-block], returning only a first
block of the CoRE Link Format description. For this reason, a block of the CoRE Link Format description. For this reason, a
CoAP client sending an IP multicast CoAP request to "/.well-known/ CoAP client sending an IP multicast CoAP request to "/.well-known/
core" SHOULD support core-block. core" SHOULD support core-block.
o A client should use CoAP group communication with the smallest o A client should use CoAP group communication with the smallest
possible IP multicast scope that fulfills the application needs. possible IP multicast scope that fulfils the application needs.
As an example, site-local scope is always preferred over global As an example, site-local scope is always preferred over global
scope IP multicast if this fulfills the application needs. scope IP multicast if this fulfils the application needs.
More guidelines specific to use of CoAP in 6LoWPAN networks [RFC4944] More guidelines specific to use of CoAP in 6LoWPAN networks [RFC4944]
are given in Section 4.5. are given in Section 4.5.
2.10. Proxy Operation 2.10. Proxy Operation
CoAP [I-D.ietf-core-coap] allows a client to request a forward-proxy CoAP [I-D.ietf-core-coap] allows a client to request a forward-proxy
to process its CoAP request. For this purpose the client either to process its CoAP request. For this purpose the client either
specifies the request group URI as a string in the Proxy-URI option, specifies the request group URI as a string in the Proxy-URI option,
or it specifies the Proxy-Scheme option with the group URI or it specifies the Proxy-Scheme option with the group URI
skipping to change at page 20, line 30 skipping to change at page 21, line 5
The two configurations using this topology are: The two configurations using this topology are:
1. Subnets are 6LoWPAN networks; the routers Rtr-1 and Rtr-2 are 1. Subnets are 6LoWPAN networks; the routers Rtr-1 and Rtr-2 are
6LoWPAN Border Routers (6LBRs, [RFC6775]). 6LoWPAN Border Routers (6LBRs, [RFC6775]).
2. Subnets are Ethernet links; the routers Rtr-1 and Rtr-2 are 2. Subnets are Ethernet links; the routers Rtr-1 and Rtr-2 are
multicast-capable Ethernet routers. multicast-capable Ethernet routers.
Both configurations are further specified by the following: Both configurations are further specified by the following:
o A large room (Room-A) with three lights (Light-1, Light-2, o A large room (Room-A) with three lights (Light-1, Light-2, Light-
Light-3) controlled by a Light Switch. The devices are organized 3) controlled by a Light Switch. The devices are organized into
into two subnets. In reality, there could be more lights (up to two subnets. In reality, there could be more lights (up to
several hundreds) but these are not shown for clarity. several hundreds) but these are not shown for clarity.
o Light-1 and the Light Switch are connected to a router (Rtr-1). o Light-1 and the Light Switch are connected to a router (Rtr-1).
o Light-2 and the Light-3 are connected to another router (Rtr-2). o Light-2 and the Light-3 are connected to another router (Rtr-2).
o The routers are connected to an IPv6 network backbone which is o The routers are connected to an IPv6 network backbone which is
also multicast enabled. In the general case, this means the also multicast enabled. In the general case, this means the
network backbone and Rtr-1/Rtr-2 support a PIM based multicast network backbone and Rtr-1/Rtr-2 support a PIM based multicast
routing protocol, and Multicast Listener Discovery (MLD) for routing protocol, and Multicast Listener Discovery (MLD) for
skipping to change at page 29, line 12 skipping to change at page 30, line 12
Once the Resource Directory (RD) is discovered, the Switches and Once the Resource Directory (RD) is discovered, the Switches and
Lights need to be discovered and their groups need to be defined. Lights need to be discovered and their groups need to be defined.
For the commissioning of these devices, a commissioning tool can be For the commissioning of these devices, a commissioning tool can be
used that defines the entries in the RD. The commissioning tool has used that defines the entries in the RD. The commissioning tool has
the authority to change the contents of the RD and the Light/Switch the authority to change the contents of the RD and the Light/Switch
nodes. DTLS based security is used by the commissioning tool to nodes. DTLS based security is used by the commissioning tool to
modify operational data in RD, Switches and Lights. modify operational data in RD, Switches and Lights.
In our particular use case, a group of three lights is defined with In our particular use case, a group of three lights is defined with
one IP multicast address and hostname one IP multicast address and hostname "Room-
"Room-A-Lights.floor1.west.bldg6.example.com". The commissioning A-Lights.floor1.west.bldg6.example.com". The commissioning tool has
tool has a list of the three lights and the associated IP multicast a list of the three lights and the associated IP multicast address.
address. For each light in the list the tool learns the IP address For each light in the list the tool learns the IP address of the
of the light and instructs the RD with three (unicast) POST commands light and instructs the RD with three (unicast) POST commands to
to store the endpoints associated with the three lights as prescribed store the endpoints associated with the three lights as prescribed by
by the RD specification [I-D.ietf-core-resource-directory]. Finally the RD specification [I-D.ietf-core-resource-directory]. Finally the
the commissioning tool defines the group in the RD to contain these commissioning tool defines the group in the RD to contain these three
three endpoints. Also the commissioning tool writes the IP multicast endpoints. Also the commissioning tool writes the IP multicast
address in the Light endpoints with, for example, the (unicast) POST address in the Light endpoints with, for example, the (unicast) POST
command discussed in Section 2.7.2.2. command discussed in Section 2.7.2.2.
The light switch can discover the group in RD and thus learn the IP The light switch can discover the group in RD and thus learn the IP
multicast address of the group. The light switch will use this multicast address of the group. The light switch will use this
address to send CoAP group communication requests to the members of address to send CoAP group communication requests to the members of
the group. When the message arrives the Lights should recognize the the group. When the message arrives the Lights should recognize the
IP multicast address and accept the message. IP multicast address and accept the message.
4. Deployment Guidelines 4. Deployment Guidelines
skipping to change at page 30, line 5 skipping to change at page 31, line 5
may require multiple IP hops for some pairs of nodes to reach each may require multiple IP hops for some pairs of nodes to reach each
other. other.
Each topology may pose different requirements on the configuration of Each topology may pose different requirements on the configuration of
routers and protocol(s), in order to enable efficient CoAP group routers and protocol(s), in order to enable efficient CoAP group
communication. To enable all the above target network topologies, an communication. To enable all the above target network topologies, an
implementation of CoAP group communication needs to allow: implementation of CoAP group communication needs to allow:
1. Routing/forwarding of IP multicast packets over multiple hops 1. Routing/forwarding of IP multicast packets over multiple hops
2. Routing/forwarding of IP multicast packets over subnet boundaries 2. Routing/forwarding of IP multicast packets over subnet boundaries
between traditional and constrained (e.g. LLN) networks. between traditional and constrained (e.g. LLN) networks.
The remainder of this section discusses solutions to enable both The remainder of this section discusses solutions to enable both
features. features.
4.2. Networks Using the MLD Protocol 4.2. Networks Using the MLD Protocol
CoAP nodes that are IP hosts (i.e., not IP routers) are generally CoAP nodes that are IP hosts (i.e., not IP routers) are generally
unaware of the specific IP multicast routing/forwarding protocol unaware of the specific IP multicast routing/forwarding protocol
being used. When such a host needs to join a specific (CoAP) being used. When such a host needs to join a specific (CoAP)
multicast group, it requires a way to signal to IP multicast routers multicast group, it requires a way to signal to IP multicast routers
skipping to change at page 32, line 49 skipping to change at page 33, line 49
these threats are summarized. these threats are summarized.
5.1. Security Configuration 5.1. Security Configuration
As defined in [I-D.ietf-core-coap], CoAP group communication based on As defined in [I-D.ietf-core-coap], CoAP group communication based on
IP multicast: IP multicast:
o Will operate in CoAP NoSec (No Security) mode, until a future o Will operate in CoAP NoSec (No Security) mode, until a future
group security solution is developed (see also Section 5.3.3). group security solution is developed (see also Section 5.3.3).
o MUST NOT use "coaps" scheme. That is, all group communication o Will use "coap" scheme mode. The "coaps" scheme should only be
MUST use only "coap" scheme. used when a future group security solution is developed (see also
Section 5.3.3).
5.2. Threats 5.2. Threats
Essentially the above configuration means that there is no security Essentially the above configuration means that there is currently no
at the CoAP layer for group communication. This is due to the fact security at the CoAP layer for group communication. This is due to
that the current DTLS based approach for CoAP is exclusively unicast the fact that the current DTLS based approach for CoAP is exclusively
oriented and does not support group security features such as group unicast oriented and does not support group security features such as
key exchange and group authentication. As a direct consequence of group key exchange and group authentication. As a direct consequence
this, CoAP group communication is vulnerable to all attacks mentioned of this, CoAP group communication is vulnerable to all attacks
in [I-D.ietf-core-coap] for IP multicast. mentioned in [I-D.ietf-core-coap] for IP multicast.
5.3. Threat Mitigation 5.3. Threat Mitigation
The [I-D.ietf-core-coap] identifies various threat mitigation The [I-D.ietf-core-coap] identifies various threat mitigation
techniques for CoAP group communication. In addition to those techniques for CoAP group communication. In addition to those
guidelines, it is recommended that for sensitive data or safety- guidelines, it is recommended that for sensitive data or safety-
critical control, a combination of appropriate link-layer security critical control, a combination of appropriate link-layer security
and administrative control of IP multicast boundaries should be used. and administrative control of IP multicast boundaries should be used.
Some examples are given below. Some examples are given below.
skipping to change at page 34, line 8 skipping to change at page 35, line 8
(6LoWPAN-bound) IP multicast traffic. Another example topology could (6LoWPAN-bound) IP multicast traffic. Another example topology could
be a multi-subnet 6LoWPAN in a large conference room. In this case, be a multi-subnet 6LoWPAN in a large conference room. In this case,
the backbone can implement port authentication (IEEE 802.1X) to the backbone can implement port authentication (IEEE 802.1X) to
ensure only authorized devices can join the Ethernet backbone. The ensure only authorized devices can join the Ethernet backbone. The
access router to this secured network segment can also be configured access router to this secured network segment can also be configured
to block incoming IP multicast traffic. to block incoming IP multicast traffic.
5.3.3. Future Evolution 5.3.3. Future Evolution
In the future, to further mitigate the threats, the developing In the future, to further mitigate the threats, the developing
approach for DTLS-based IP multicast security for CoAP networks (see approach for DTLS-based IP multicast security for CoAP communications
[I-D.keoh-tls-multicast-security]) or similar approaches should be (see [I-D.keoh-dice-multicast-security]) or similar approaches should
considered once they mature. be considered. This will allow introduction of a secure mode of CoAP
group communication, and use of the "coaps" scheme for that purpose.
6. IANA Considerations 5.4. Pervasive Monitoring Considerations
A key additional threat consideration for group communication is
pointed to by [RFC7258] which warns of the dangers of pervasive
monitoring. CoAP group communication which is built on top of IP
multicast should pay particular heed to these dangers. This is
because IP multicast is easier to intercept (e.g. and to secretly
record) compared to unicast traffic. Also, CoAP traffic is meant for
the Internet of Things. This means that CoAP traffic is often used
for the control and monitoring of critical infrastructure (e.g.
lights, alarms, etc.) which may be prime targets for attack.
For example, an attacker may attempt to record all the CoAP traffic
going over the smart grid (i.e. networked electrical utility) of a
country and try to determine critical control nodes for further
attacks. CoAP multicast traffic is inherently more vulnerable
(compared to a unicast packet) as the same packet may be replicated
over many links so there is a much higher probability of it getting
captured by a pervasive monitoring system.
One useful mitigation to pervasive monitoring is to restrict the
scope of the IP multicast to the minimal scope that fulfils the
application need. Thus, for example, site-local IP multicast scope
is always preferred over global scope IP multicast if this fulfils
the application needs. This approach has the added advantage that it
coincides with the guidelines for minimizing congestion control (see
Section 2.9.
In the future, even if all the CoAP multicast traffic is encrypted
(e.g. [I-D.keoh-dice-multicast-security]), an attacker may still
attempt to capture the traffic and perform an off-line attack.
Though of course having the multicast traffic protected is always
desirable as it significantly raises the cost to an attacker (e.g. to
break the encryption) versus unprotected multicast traffic.
6. IANA Considerations
6.1. New 'core.gp' Resource Type 6.1. New 'core.gp' Resource Type
This memo registers a new resource type (rt) from the CoRE Parameters This memo registers a new resource type (rt) from the CoRE Parameters
Registry called 'core.gp'. Registry called 'core.gp'.
(Note to IANA/RFC Editor: This registration follows the process (Note to IANA/RFC Editor: This registration follows the process
described in section 7.4 of [RFC6690]). described in section 7.4 of [RFC6690]).
Attribute Value: core.gp Attribute Value: core.gp
skipping to change at page 37, line 31 skipping to change at page 39, line 21
Format", RFC 6690, August 2012. Format", RFC 6690, August 2012.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
Structured Syntax Suffixes", RFC 6839, January 2013. Structured Syntax Suffixes", RFC 6839, January 2013.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014.
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18 Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013. (work in progress), June 2013.
8.2. Informative References 8.2. Informative References
[I-D.ietf-core-block] [I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
draft-ietf-core-block-14 (work in progress), October 2013. draft-ietf-core-block-14 (work in progress), October 2013.
[I-D.ietf-roll-trickle-mcast] [I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle- and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-05 (work in progress), August 2013. mcast-09 (work in progress), April 2014.
[I-D.keoh-tls-multicast-security] [I-D.keoh-dice-multicast-security]
Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A.
Security for Low-Power and Lossy Networks (LLNs)", draft- Rahman, "DTLS-based Multicast Security in Constrained
keoh-tls-multicast-security-00 (work in progress), October Environments", draft-keoh-dice-multicast-security-07 (work
2012. in progress), May 2014.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource
Directory", draft-ietf-core-resource-directory-00 (work in Directory", draft-ietf-core-resource-directory-01 (work in
progress), June 2013. progress), December 2013.
[I-D.ietf-appsawg-uri-get-off-my-lawn] [I-D.ietf-appsawg-uri-get-off-my-lawn]
Nottingham, M., "Standardising Structure in URIs", draft- Nottingham, M., "URI Design and Ownership", draft-ietf-
ietf-appsawg-uri-get-off-my-lawn-00 (work in progress), appsawg-uri-get-off-my-lawn-05 (work in progress), May
September 2013. 2014.
[I-D.droms-6man-multicast-scopes] [I-D.droms-6man-multicast-scopes]
Droms, R., "IPv6 Multicast Address Scopes", draft-droms- Droms, R., "IPv6 Multicast Address Scopes", draft-droms-
6man-multicast-scopes-02 (work in progress), July 2013. 6man-multicast-scopes-02 (work in progress), July 2013.
Appendix A. Multicast Listener Discovery (MLD) Appendix A. Multicast Listener Discovery (MLD)
In order to extend the scope of IP multicast beyond link-local scope, In order to extend the scope of IP multicast beyond link-local scope,
an IP multicast routing or forwarding protocol has to be active in an IP multicast routing or forwarding protocol has to be active in
routers on an LLN. To achieve efficient IP multicast routing (i.e., routers on an LLN. To achieve efficient IP multicast routing (i.e.,
skipping to change at page 38, line 44 skipping to change at page 40, line 39
which IP multicast listeners may join and leave at any time. which IP multicast listeners may join and leave at any time.
[RFC6636] discusses optimal tuning of the parameters of MLD/IGMP for [RFC6636] discusses optimal tuning of the parameters of MLD/IGMP for
routers for mobile and wireless networks. These guidelines may be routers for mobile and wireless networks. These guidelines may be
useful when implementing MLD in LLNs. useful when implementing MLD in LLNs.
Appendix B. Change Log Appendix B. Change Log
[Note to RFC Editor: Please remove this section before publication.] [Note to RFC Editor: Please remove this section before publication.]
Changes from ietf-18 to ietf-19:
o Added guideline on Token value re-use in section 2.5.
o Updated section 5.1 (Security Configuration) and 5.3.3 (Future
Security Evolution) to point to latest security developments
happening in DICE WG for support of group security.
o Added Pervasive Monitoring considerations in section 5.4.
o Various editorial updates for improved readability.
Changes from ietf-17 to ietf-18: Changes from ietf-17 to ietf-18:
o Extensive editorial updates based on WGLC comments by Thomas o Extensive editorial updates based on WGLC comments by Thomas
Fossati and Gengyu Wei. Fossati and Gengyu Wei.
o Addressed ticket #361: Added text for single membership PUT o Addressed ticket #361: Added text for single membership PUT
section 2.7.2.7 (Updating a single group membership (PUT)). section 2.7.2.7 (Updating a single group membership (PUT)).
o Addressed ticket #360: Added text for server duties upon all-at- o Addressed ticket #360: Added text for server duties upon all-at-
once PUT section 2.7.2.6 (Creating/updating all group memberships once PUT section 2.7.2.6 (Creating/updating all group memberships
skipping to change at page 46, line 18 skipping to change at page 48, line 22
o Added mechanism for group membership configuration (#249). o Added mechanism for group membership configuration (#249).
o Removed IANA request for multicast addresses (section 7) and o Removed IANA request for multicast addresses (section 7) and
replaced with a note indicating that the request is being made in replaced with a note indicating that the request is being made in
[I-D.ietf-core-coap] (#248). [I-D.ietf-core-coap] (#248).
o Made the definition of 'group' more specific to group of CoAP o Made the definition of 'group' more specific to group of CoAP
endpoints and included text on UDP port selection (#186). endpoints and included text on UDP port selection (#186).
o Added explanatory text in section 3.4 regarding why not to use o Added explanatory text in section 3.4 regarding why not to use
group communication for non-idempotent messages (i.e. CoAP POST) group communication for non-idempotent messages (i.e. CoAP POST)
(#186). (#186).
o Changed link-local RD discovery to site-local in RD discovery use o Changed link-local RD discovery to site-local in RD discovery use
case to make it more realistic. case to make it more realistic.
o Fixed lighting control use case CoAP proxying; now returns o Fixed lighting control use case CoAP proxying; now returns
individual CoAP responses as in coap-12. individual CoAP responses as in coap-12.
o Replaced link format I-D with RFC6690 reference. o Replaced link format I-D with RFC6690 reference.
 End of changes. 29 change blocks. 
86 lines changed or deleted 164 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/