5. Security Considerations
This section describes the relevant security configuration for CoAP
group communication using IP multicast. The threats to CoAP group
communication are also identified, and various approaches to mitigate
these threats are summarized.
5.1. Security Configuration
As defined in Sections 8.1 and 9.1 of [RFC7252], CoAP group
communication based on IP multicast will do the following:
o Operate in CoAP NoSec (No Security) mode, until a future group
security solution is developed (see also Section 5.3.3).
o Use the "coap" scheme. The "coaps" scheme should only be used
when a future group security solution is developed (see also
Essentially, the above configuration means that there is currently no
security at the CoAP layer for group communication. Therefore, for
sensitive and mission-critical applications (e.g., health monitoring
systems and alarm monitoring systems), it is currently recommended to
deploy CoAP group communication with an application-layer security
mechanism (e.g., data object security) for improved security.
Application-level security has many desirable properties, including
maintaining security properties while forwarding traffic through
intermediaries (proxies). Application-level security also tends to
more cleanly separate security from the dynamics of group membership
(e.g., the problem of distributing security keys across large groups
with many members that come and go).
Without application-layer security, CoAP group communication should
only be currently deployed in non-critical applications (e.g., read-
only temperature sensors). Only when security solutions at the CoAP
layer are mature enough (see Section 5.3.3) should CoAP group
communication without application-layer security be considered for
sensitive and mission-critical applications.
As noted above, there is currently no security at the CoAP layer for
group communication. This is due to the fact that the current DTLS-
based approach for CoAP is exclusively unicast oriented and does not
support group security features such as group key exchange and group
authentication. As a direct consequence of this, CoAP group
communication is vulnerable to all attacks mentioned in Section 11 of
[RFC7252] for IP multicast.
5.3. Threat Mitigation
Section 11 of [RFC7252] identifies various threat mitigation
techniques for CoAP group communication. In addition to those
guidelines, it is recommended that for sensitive data or safety-
critical control, a combination of appropriate link-layer security
and administrative control of IP multicast boundaries should be used.
Some examples are given below.
5.3.1. WiFi Scenario
In a home automation scenario (using WiFi), the WiFi encryption
should be enabled to prevent rogue nodes from joining. The Customer
Premises Equipment (CPE) that enables access to the Internet should
also have its IP multicast filters set so that it enforces multicast
scope boundaries to isolate local multicast groups from the rest of
the Internet (e.g., as per [RFC6092]). In addition, the scope of the
IP multicast should be set to be site-local or smaller scope. For
site-local scope, the CPE will be an appropriate multicast scope
5.3.2. 6LoWPAN Scenario
In a building automation scenario, a particular room may have a
single 6LoWPAN network with a single edge router (6LBR). Nodes on
the subnet can use link-layer encryption to prevent rogue nodes from
joining. The 6LBR can be configured so that it blocks any incoming
(6LoWPAN-bound) IP multicast traffic. Another example topology could
be a multi-subnet 6LoWPAN in a large conference room. In this case,
the backbone can implement port authentication (IEEE 802.1X) to
ensure only authorized devices can join the Ethernet backbone. The
access router to this secured network segment can also be configured
to block incoming IP multicast traffic.
5.3.3. Future Evolution
In the future, to further mitigate the threats, security enhancements
need to be developed at the IETF for group communications. This will
allow introduction of a secure mode of CoAP group communication and
use of the "coaps" scheme for that purpose.
At the time of writing this specification, there are various
approaches being considered for security enhancements for group
communications. Specifically, a lot of the current effort at the
IETF is geared towards developing DTLS-based group communication.
This is primarily motivated by the fact that unicast CoAP security is
DTLS based (Section 9.1 of [RFC7252]. For example, [MCAST-SECURITY]
proposes DTLS-based IP multicast security. However, it is too early
to conclude if this is the best approach. Alternatively,
[IPSEC-PAYLOAD] proposes IPsec-based IP multicast security. This
approach also needs further investigation and validation.
5.4. Monitoring Considerations
5.4.1. General Monitoring
CoAP group communication is meant to be used to control a set of
related devices (e.g., simultaneously turn on all the lights in a
room). This intrinsically exposes the group to some unique
monitoring risks that solitary devices (i.e., devices not in a group)
are not as vulnerable to. For example, assume an attacker is able to
physically see a set of lights turn on in a room. Then the attacker
can correlate a CoAP group communication message to that easily
observable coordinated group action even if the contents of the
message are encrypted by a future security solution (see
Section 5.3.3). This will give the attacker side-channel information
to plan further attacks (e.g., by determining the members of the
group, then some network topology information may be deduced).
One mitigation to group communication monitoring risks that should be
explored in the future is methods to decorrelate coordinated group
actions. For example, if a CoAP group communication GET is sent to
all the alarm sensors in a house, then their (unicast) responses
should be as decorrelated as possible. This will introduce greater
entropy into the system and will make it harder for an attacker to
monitor and gather side-channel information.
5.4.2. Pervasive Monitoring
A key additional threat consideration for group communication is
pointed to by [RFC7258], which warns of the dangers of pervasive
monitoring. CoAP group communication solutions that are built on top
of IP multicast need to 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 (once future
security solutions are developed as in Section 5.3.3) may be used for
the control and monitoring of critical infrastructure (e.g., lights,
alarms, etc.) that 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 nodes for further attacks. For
example, the source node (controller) sends out the CoAP group
communication messages. 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 fulfills the
application need. Thus, for example, site-local IP multicast scope
is always preferred over global scope IP multicast if this fulfills
the application needs. This approach has the added advantage that it
coincides with the guidelines for minimizing congestion control (see
In the future, even if all the CoAP multicast traffic is encrypted,
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
6. IANA Considerations
6.1. New 'core.gp' Resource Type
This memo registers a new Resource Type (rt=) Link Target Attribute,
'core.gp', in the "Resource Type (rt=) Link Target Attribute Values"
subregistry under the "Constrained RESTful Environments (CoRE)
Attribute Value: core.gp
Description: Group Configuration resource. This resource is used to
query/manage the group membership of a CoAP server.
Reference: See Section 2.6.2.
6.2. New 'coap-group+json' Internet Media Type
This memo registers a new Internet media type for the CoAP Group
Configuration resource called 'application/coap-group+json'.
Type name: application
Subtype name: coap-group+json
Required parameters: None
Optional parameters: None
Encoding considerations: 8-bit UTF-8.
JSON to be represented using UTF-8, which is 8-bit compatible (and
most efficient for resource constrained implementations).
Denial-of-Service attacks could be performed by constantly
(re-)setting the Group Configuration resource of a CoAP endpoint to
different values. This will cause the endpoint to register (or
deregister) from the related IP multicast group. To prevent this, it
is recommended that a form of authorization (making use of unicast
DTLS-secured CoAP) be used such that only authorized controllers are
allowed by an endpoint to configure its group membership.
Interoperability considerations: None
Published specification: RFC 7390
Applications that use this media type:
CoAP client and server implementations that wish to set/read the
Group Configuration resource via the 'application/coap-group+json'
payload as described in Section 2.6.2.
Fragment identifier considerations: N/A
Deprecated alias names for this type: None
Magic number(s): None
File extension(s): *.json
Macintosh file type code(s): TEXT
Person and email address to contact for further information:
Esko Dijk ("Esko.Dijk@Philips.com")
Intended usage: COMMON
Restrictions on usage: None
Author: CoRE WG
Change controller: IETF
Provisional registration? (standards tree only): N/A
Appendix A. Multicast Listener Discovery (MLD)
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
routers on an LLN. To achieve efficient IP multicast routing (i.e.,
avoid always flooding IP multicast packets), routers have to learn
which hosts need to receive packets addressed to specific IP
The MLD protocol [RFC3810] (or its IPv4 equivalent, IGMP [RFC3376])
is today the method of choice used by a (IP multicast-enabled) router
to discover the presence of IP multicast listeners on directly
attached links, and to discover which IP multicast addresses are of
interest to those listening nodes. MLD was specifically designed to
cope with fairly dynamic situations in which IP multicast listeners
may join and leave at any time.
Optimal tuning of the parameters of MLD/IGMP for routers for mobile
and wireless networks is discussed in [RFC6636]. These guidelines
may be useful when implementing MLD in LLNs.
Thanks to Jari Arkko, Peter Bigot, Anders Brandt, Ben Campbell,
Angelo Castellani, Alissa Cooper, Spencer Dawkins, Badis Djamaa,
Adrian Farrel, Stephen Farrell, Thomas Fossati, Brian Haberman,
Bjoern Hoehrmann, Matthias Kovatsch, Guang Lu, Salvatore Loreto,
Kerry Lynn, Andrew McGregor, Kathleen Moriarty, Pete Resnick, Dale
Seed, Zach Shelby, Martin Stiemerling, Peter van der Stok, Gengyu
Wei, and Juan Carlos Zuniga for their helpful comments and
discussions that have helped shape this document.
Special thanks to Carsten Bormann and Barry Leiba for their extensive
and thoughtful Chair and AD reviews of the document. Their reviews
helped to immeasurably improve the document quality.