< draft-keoh-dice-multicast-security-06.txt		draft-keoh-dice-multicast-security-07.txt >
	DICE Working Group S. Keoh		DICE Working Group S. Keoh
	Internet-Draft University of Glasgow Singapore		Internet-Draft University of Glasgow Singapore
	Intended status: Standards Track S. Kumar, Ed.		Intended status: Standards Track S. Kumar, Ed.
	Expires: November 6, 2014 O. Garcia-Morchon		Expires: November 10, 2014 O. Garcia-Morchon
	E. Dijk		E. Dijk
	Philips Research		Philips Research
	A. Rahman		A. Rahman
	InterDigital		InterDigital
	May 5, 2014		May 9, 2014
	DTLS-based Multicast Security in Constrained Environments		DTLS-based Multicast Security in Constrained Environments
	draft-keoh-dice-multicast-security-06		draft-keoh-dice-multicast-security-07
	Abstract		Abstract
	The CoAP standard is fast emerging as a key protocol in the area of		The CoAP standard is fast emerging as a key protocol in the area of
	resource-constrained devices. Such IP-based systems are foreseen to		resource-constrained devices. Such IP-based systems are foreseen to
	be used for building and lighting control systems where devices		be used for building and lighting control systems where devices
	interconnect with each other, forming, for example, low-power and		interconnect with each other, forming, for example, low-power and
	lossy networks (LLNs). Both multicast and its security are key needs		lossy networks (LLNs). Both multicast and its security are key needs
	in these networks. This draft presents a method for securing IPv6		in these networks. This draft presents a method for securing IPv6
	multicast communication based on the DTLS which is already supported		multicast communication based on the DTLS which is already supported
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 6, 2014.		This Internet-Draft will expire on November 10, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	4.2. Record layer adaptation . . . . . . . . . . . . . . . . . 12		4.2. Record layer adaptation . . . . . . . . . . . . . . . . . 12
	4.3. Sending Secure Multicast Messages . . . . . . . . . . . . 14		4.3. Sending Secure Multicast Messages . . . . . . . . . . . . 14
	4.4. Receiving Secure Multicast Messages . . . . . . . . . . . 14		4.4. Receiving Secure Multicast Messages . . . . . . . . . . . 14
	4.5. Unicast Responses to Multicast Messages . . . . . . . . . 15		4.5. Unicast Responses to Multicast Messages . . . . . . . . . 15
	4.6. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 16		4.6. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 16
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6.1. Group level security . . . . . . . . . . . . . . . . . . 16		6.1. Group level security . . . . . . . . . . . . . . . . . . 16
	6.2. Late joiners . . . . . . . . . . . . . . . . . . . . . . 17		6.2. Late joiners . . . . . . . . . . . . . . . . . . . . . . 17
	6.3. Uniqueness of SenderIDs . . . . . . . . . . . . . . . . . 17		6.3. Uniqueness of SenderIDs . . . . . . . . . . . . . . . . . 17
	6.4. Reduced sequence number space . . . . . . . . . . . . . . 17		6.4. Reduced sequence number space . . . . . . . . . . . . . . 18
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	There is an increased use of wireless control networks in		There is an increased use of wireless control networks in
	environmental monitoring, industrial automation, lighting controls		environmental monitoring, industrial automation, lighting controls
	and building management systems. This is mainly driven by the fact		and building management systems. This is mainly driven by the fact
	that the independence from physical control wires allows for freedom		that the independence from physical control wires allows for freedom
	of placement, portability and for reducing the cost of installation		of placement, portability and for reducing the cost of installation
	skipping to change at page 15, line 38 ¶		skipping to change at page 15, line 38 ¶
	4.5. Unicast Responses to Multicast Messages		4.5. Unicast Responses to Multicast Messages
	In CoAP, responses to multicast messages are always sent back as		In CoAP, responses to multicast messages are always sent back as
	unicast. That is, the group members that receive a multicast message		unicast. That is, the group members that receive a multicast message
	may individually decide to send (or suppress) a unicast response as		may individually decide to send (or suppress) a unicast response as
	described in Section 2.5 of [I-D.ietf-core-groupcomm]. The unicast		described in Section 2.5 of [I-D.ietf-core-groupcomm]. The unicast
	responses to a DTLS-based multicast message may optionally be secure.		responses to a DTLS-based multicast message may optionally be secure.
	Specifically, the unicast response may be sent back as a unicast DTLS		Specifically, the unicast response may be sent back as a unicast DTLS
	as described in Section 9.1 of [I-D.ietf-core-coap]. This requires		as described in Section 9.1 of [I-D.ietf-core-coap]. This requires
	that a unicast DTLS handshake was previously initiated between the		that a unicast DTLS handshake was previously initiated between the
	multicast message sender and listener. In the extreme scenario, a		multicast message sender and listener.
	multicast sender may attempt to initiate the unicast DTLS handshake
	with all or a subset of known listeners just before or just after it		Either the multicast message sender or listener may initiate the
	sends out the DTLS-based multicast message. This may result in the		unicast DTLS handshake. If the DTLS handshake was initiated by the
	multicast sender (i.e. unicast DTLS client) having to process unicast		multicast message sender, it requires that the sender be aware of the
	DTLS handshake messages from multiple multicast listeners (i.e.		membership of the multicast group. This can be accomplished, for
	unicast DTLS servers) in a short period.		example, as described in Section 2.6 of [I-D.ietf-core-coap]. If the
			listener initiated the DTLS handshake, it may have done so, for
			example, after receiving a multicast message for the first time.
			In the extreme scenario, a multicast sender may attempt to initiate
			the unicast DTLS handshake with all, or a subset of, known listeners
			just after it sends out the DTLS-based multicast message. This may
			result in the multicast sender having to process unicast DTLS
			handshake messages from multiple multicast listeners in a short
			period.
	Note: There is an obvious timing and processing load issue for the		Note: There is an obvious timing and processing load issue for the
	multicast sender in the scenario where it attempts to initiate the		multicast sender in the scenario where it attempts to initiate the
	unicast DTLS handshakes with all/some of its known listeners just		unicast DTLS handshakes with all/some of its known listeners just
	after it sends out the DTLS-based multicast message. In this case,		after it sends out the DTLS-based multicast message. In this case,
	the processing load in the multicast sender (i.e. unicast DTLS		the processing load in the multicast sender (i.e. unicast DTLS
	client) is reduced somewhat by the fact that CoAP requires a back-off		client) is reduced somewhat by the fact that CoAP requires a back-off
	and randomization of the unicast response by the Leisure timer		and randomization of the unicast response by the Leisure timer
	mechanism as described in Section 8.2 of [I-D.ietf-core-coap].		mechanism as described in Section 8.2 of [I-D.ietf-core-coap].
End of changes. 7 change blocks.
	13 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/