RFC 7390
Group Communication for the Constrained Application Protocol (CoAP)
Pages: 46
Experimental
Experimental
Part 3 of 3 – Pages 35 to 46
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
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.
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.
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 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 '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) Parameters" registry. 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).
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 ("Esko.Dijk@Philips.com") Intended usage: COMMON Restrictions on usage: None Author: CoRE WG Change controller: IETF Provisional registration? (standards tree only): N/A
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, <http://www.rfc-editor.org/info/rfc2119>. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>. [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002, <http://www.rfc-editor.org/info/rfc3433>. [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003, <http://www.rfc-editor.org/info/rfc3542>. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.
[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, <http://www.rfc-editor.org/info/rfc4919>. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>. [RFC5110] Savola, P., "Overview of the Internet Multicast Routing Architecture", RFC 5110, January 2008, <http://www.rfc-editor.org/info/rfc5110>. [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010, <http://www.rfc-editor.org/info/rfc5771>. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>. [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011, <http://www.rfc-editor.org/info/rfc6092>. [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, <http://www.rfc-editor.org/info/rfc6550>. [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, <http://www.rfc-editor.org/info/rfc6636>. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[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, <http://www.rfc-editor.org/info/rfc6775>. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>. [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>. [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>. [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, July 2014, <http://www.rfc-editor.org/info/rfc7320>.7.2. Informative References
[RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1033, November 1987, <http://www.rfc-editor.org/info/rfc1033>. [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, <http://www.rfc-editor.org/info/rfc4605>. [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009, <http://www.rfc-editor.org/info/rfc5740>. [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, August 2014, <http://www.rfc-editor.org/info/rfc7346>. [BLOCKWISE-CoAP] Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", Work in Progress, draft-ietf-core-block-15, July 2014.
[CoRE-RD] Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource- directory-01, December 2013. [OBSERVE-CoAP] Hartke, K., "Observing Resources in CoAP", Work in Progress, draft-ietf-core-observe-14, June 2014. [MCAST-MPL] 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. [MCAST-SECURITY] 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. [IPSEC-PAYLOAD] Migault, D. and C. Bormann, "IPsec/ESP for Application Payload", Work in Progress, draft-mglt-dice-ipsec-for- application-payload-00, July 2014.
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.Acknowledgements
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.
Authors' Addresses
Akbar Rahman (editor) InterDigital Communications, LLC 1000 Sherbrooke Street West Montreal, Quebec H3A 3G4 Canada EMail: Akbar.Rahman@InterDigital.com Esko Dijk (editor) Philips Research High Tech Campus 34 Eindhoven 5656AE Netherlands EMail: esko.dijk@philips.com