Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7390

Group Communication for the Constrained Application Protocol (CoAP)

Pages: 46
Part 3 of 3 – Pages 35 to 46
First   Prev   None

Top   ToC   RFC7390 - Page 35   prevText

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   ToC   RFC7390 - 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   ToC   RFC7390 - 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   ToC   RFC7390 - 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   ToC   RFC7390 - 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   ToC   RFC7390 - 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   ToC   RFC7390 - 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   ToC   RFC7390 - 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   ToC   RFC7390 - 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, <>. [BLOCKWISE-CoAP] Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", Work in Progress, draft-ietf-core-block-15, July 2014.
Top   ToC   RFC7390 - 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   ToC   RFC7390 - 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   ToC   RFC7390 - Page 46

Authors' Addresses

Akbar Rahman (editor) InterDigital Communications, LLC 1000 Sherbrooke Street West Montreal, Quebec H3A 3G4 Canada EMail: Esko Dijk (editor) Philips Research High Tech Campus 34 Eindhoven 5656AE Netherlands EMail: