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. Section 11 of [RFC7252] for IP multicast. 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.
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. 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.
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. 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. Section 2.6.2.
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
[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>.
[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.
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.