Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 7390


Group Communication for the Constrained Application Protocol (CoAP)

Part 3 of 3, p. 35 to 46
Prev RFC Part


prevText      Top      Up      ToC       Page 35 
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).

Top      Up      ToC       Page 36 
   o  Use the "coap" scheme.  The "coaps" scheme should only be used
      when a future group security solution is developed (see also
      Section 5.3.3).

   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.

5.2.  Threats

   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.

Top      Up      ToC       Page 37 
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
   boundary point.

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.

Top      Up      ToC       Page 38 
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.

Top      Up      ToC       Page 39 
   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
   Section 2.8).

   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
   multicast traffic.

6.  IANA Considerations

6.1.  New '' Resource Type

   This memo registers a new Resource Type (rt=) Link Target Attribute,
   '', in the "Resource Type (rt=) Link Target Attribute Values"
   subregistry under the "Constrained RESTful Environments (CoRE)
   Parameters" registry.

   Attribute Value:

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

Top      Up      ToC       Page 40 
   Security considerations:

   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

   Additional Information:

      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 ("")

   Intended usage: COMMON

   Restrictions on usage: None

   Author: CoRE WG

   Change controller: IETF

   Provisional registration? (standards tree only): N/A

Top      Up      ToC       Page 41 
7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000, <>.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002,

   [RFC3433]  Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor
              Management Information Base", RFC 3433, December 2002,

   [RFC3542]  Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
              "Advanced Sockets Application Program Interface (API) for
              IPv6", RFC 3542, May 2003,

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004,

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005,

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006,

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006,

Top      Up      ToC       Page 42 
   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals", RFC
              4919, August 2007,

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007,

   [RFC5110]  Savola, P., "Overview of the Internet Multicast Routing
              Architecture", RFC 5110, January 2008,

   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
              IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
              March 2010, <>.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952, August 2010,

   [RFC6092]  Woodyatt, J., "Recommended Simple Security Capabilities in
              Customer Premises Equipment (CPE) for Providing
              Residential IPv6 Internet Service", RFC 6092, January
              2011, <>.

   [RFC6550]  Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
              Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
              Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
              Lossy Networks", RFC 6550, March 2012,

   [RFC6636]  Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of
              the Internet Group Management Protocol (IGMP) and
              Multicast Listener Discovery (MLD) for Routers in Mobile
              and Wireless Networks", RFC 6636, May 2012,

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, August 2012,

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, February 2013,

Top      Up      ToC       Page 43 
   [RFC6775]  Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
              "Neighbor Discovery Optimization for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
              November 2012, <>.

   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, March 2014,

   [RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
              2014, <>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014,

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, May 2014,

   [RFC7320]  Nottingham, M., "URI Design and Ownership", BCP 190, RFC
              7320, July 2014, <>.

7.2.  Informative References

   [RFC1033]  Lottor, M., "Domain administrators operations guide", RFC
              1033, November 1987,

   [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, August 2006,

   [RFC5740]  Adamson, B., Bormann, C., Handley, M., and J. Macker,
              "NACK-Oriented Reliable Multicast (NORM) Transport
              Protocol", RFC 5740, November 2009,

   [RFC7346]  Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
              August 2014, <>.

              Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
              Work in Progress, draft-ietf-core-block-15, July 2014.

Top      Up      ToC       Page 44 
   [CoRE-RD]  Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource
              Directory", Work in Progress, draft-ietf-core-resource-
              directory-01, December 2013.

              Hartke, K., "Observing Resources in CoAP", Work in
              Progress, draft-ietf-core-observe-14, June 2014.

              Hui, J. and R. Kelsey, "Multicast Protocol for Low power
              and Lossy Networks (MPL)", Work in Progress, draft-ietf-
              roll-trickle-mcast-09, April 2014.

              Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A.
              Rahman, "DTLS-based Multicast Security in Constrained
              Environments", Work in Progress, draft-keoh-dice-
              multicast-security-08, July 2014.

              Migault, D. and C. Bormann, "IPsec/ESP for Application
              Payload", Work in Progress, draft-mglt-dice-ipsec-for-
              application-payload-00, July 2014.

Top      Up      ToC       Page 45 
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
   multicast destinations.

   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.

Top      Up      ToC       Page 46 
Authors' Addresses

   Akbar Rahman (editor)
   InterDigital Communications, LLC
   1000 Sherbrooke Street West
   Montreal, Quebec  H3A 3G4


   Esko Dijk (editor)
   Philips Research
   High Tech Campus 34
   Eindhoven  5656AE