< draft-kumar-dice-dtls-relay-01.txt		draft-kumar-dice-dtls-relay-02.txt >
	DICE Working Group S. Kumar		DICE Working Group S. Kumar, Ed.
	Internet-Draft Philips Research		Internet-Draft Philips Research
	Intended status: Standards Track S. Keoh		Intended status: Standards Track S. Keoh
	Expires: October 24, 2014 University of Glasgow Singapore		Expires: April 23, 2015 University of Glasgow Singapore
	O. Garcia-Morchon		O. Garcia-Morchon
	Philips Research		Philips Research
	April 22, 2014		October 20, 2014
	DTLS Relay for Constrained Environments		DTLS Relay for Constrained Environments
	draft-kumar-dice-dtls-relay-01		draft-kumar-dice-dtls-relay-02
	Abstract		Abstract
	The 6LoWPAN and CoAP standards defined for resource-constrained		The 6LoWPAN and CoAP standards defined for resource-constrained
	devices are fast emerging as the de-facto protocols for enabling the		devices are fast emerging as the de-facto protocols for enabling the
	Internet-of-Things (IoTs). Security is an important concern in IoTs		Internet-of-Things (IoTs). Security is an important concern in IoTs
	and the DTLS protocol has been chosen as the preferred method for		and the DTLS protocol has been chosen as the preferred method for
	securing CoAP messages. DTLS is a point-to-point protocol relying on		securing CoAP messages. DTLS is a point-to-point protocol relying on
	the IP routing to deliver messages between the client and the server.		IP routing to deliver messages between the client and the server.
	However in some low-power lossy networks (LLNs) with multi-hop, a new		However in some low-power lossy networks (LLNs) with multi-hop, a new
	"joining" device may not be initially IP routable until it is		"joining" device may not be initially IP-routable. Moreover, it
	authenticated to the network. This prevents DTLS from being directly		exists in a separate, unauthenticated domain at the point of first
	useful as an authentication and confidentiality protocol during this		contact and therefore cannot be initially trusted. This puts
	stage, requiring other security protocols to be implemented on the		limitations on the ability to use DTLS as an authentication and
	device. These devices being resource-constrained often cannot		confidentiality protocol at this stage. These devices being
	accommodate more than one security protocol in their code memory. To		Resource-constrained often cannot accommodate more than one security
	overcome this problem and reuse DTLS, we present a DTLS Relay		protocol in their code memory. To overcome this problem we suggest
	solution for the non-IP routable "joining" device to establish a		DTLS as the single protocol and therefore, we present a DTLS Relay
	secure DTLS connection with a DTLS server. Further we present a		solution for the non-IP routable "joining" device to enable it to
	stateful and stateless mode of operation for the DTLS Relay.		establish a secure DTLS connection with a DTLS Server. Furthermore
			we present a stateful and stateless mode of operation for the DTLS
			Relay.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 23, 2015.
	This Internet-Draft will expire on October 24, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. DTLS relay . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. DTLS Relay . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Relay in Stateful mode . . . . . . . . . . . . . . . . . 6		3.1. DTLS Relay in Stateful mode . . . . . . . . . . . . . . . 6
	3.2. Relay in Stateless mode . . . . . . . . . . . . . . . . . 8		3.2. DTLS Relay in Stateless mode . . . . . . . . . . . . . . 8
	3.3. Comparison between the two modes . . . . . . . . . . . . 10		3.3. Comparison between the two modes . . . . . . . . . . . . 10
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . 11		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The Internet-of-Things (IoTs) vision is more closer to reality with		For the Internet of Things (IoT) to become a reality, it will require
	the IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN)		the participation of constrained nodes in constrained networks
	[RFC4944] and Constrained Application Protocol (CoAP)		[RFC7228]. These constrained nodes typically implement the IPv6 over
	[I-D.ietf-core-coap] standards . The 6LoWPAN adaptation layer allows		Low-Power Wireless Personal Area Networks (6LoWPAN) [RFC4944] and
	for transmission of IPv6 Packets over IEEE 802.15.4 networks		Constrained Application Protocol (CoAP) [RFC7252] standards. The
	[ieee802.15.4] and thereby enabling end-to-end IPv6 connectivity of		6LoWPAN adaptation layer allows for transmission of IPv6 Packets over
	"Things". CoAP is a web protocol based on REST architecture designed		IEEE 802.15.4 networks [ieee802.15.4], thereby enabling end-to-end
	to work under the special requirements of the constrained		IPv6 connectivity between constrained nodes and other devices on the
	environment. It supports binding to UDP [RFC0768] which is preferred		Internet. CoAP is a web protocol based on REST architecture designed
	over TCP [RFC0793] in low-power lossy networks (LLNs) such as IEEE		for constrained node networks. It supports binding to UDP [RFC0768],
	802.15.4.		which has advantages over TCP [RFC0793] when used in low-power lossy
			networks (LLNs) such as IEEE 802.15.4 [ieee802.15.4].
	Security is important concern in such a wireless multi-hop network		Security is an important concern in such a constrained node network,
	that could be used in various application domains such as smart		which could be used in various application domains such as smart
	energy and building automation. However security protocols are often		energy and building automation. However, security protocols are
	heavy-weight both in terms of code and network processing. Due to		often heavy-weight in terms of both code and network processing. Use
	the constrained nature of most of these devices, multiple security		of multiple security protocols for different purposes and at
	protocols for different purposes and at different networking layers		different networking layers is problematic in constrained devices,
	are hard to envision. It is more efficient to use a single security		therefore the use of a single security protocol to fulfil multiple
	protocol to fulfill multiple security requirements in such		security requirements is greatly preferred.
	constrained environments.
	CoAP has chosen Datagram Transport Layer Security (DTLS) [RFC6347] as		CoAP has chosen Datagram Transport Layer Security (DTLS) [RFC6347] as
	the preferred security protocol for authenticity and confidentiality		the preferred security protocol for authenticity and confidentiality
	of the messages. It is based on Transport Layer Security (TLS)		of the messages. It is based on Transport Layer Security (TLS)
	[RFC5246] with modifications to run over UDP. DTLS makes use of		[RFC5246] with modifications to run over UDP. DTLS makes use of
	additional reliability mechanisms in its handshake due to the lack of		additional reliability mechanisms in its handshake due to the lack of
	TCP reliable transmission mechanisms that are available to TLS.		TCP reliable transmission mechanisms that are available to TLS.
	DTLS is a point-to-point protocol relying on the underlying IP layer		DTLS is a client-server protocol relying on the underlying IP layer
	to perform the routing between the DTLS client and the DTLS server.		to perform the routing between the DTLS Client and the DTLS Server.
	However in some LLNs with multi-hop, a new "joining" device may not		However in some LLNs with multi-hop, a new "joining" device may not
	be initially IP routable until it is authenticated to the network. A		be initially IP routable until it is authenticated to the network. A
	new "joining" device can only initially use a link-local IPv6 address		new "joining" device can only initially use a link-local IPv6 address
	to communicate with a neighbour node using neighbour discovery		to communicate with a neighbour node using neighbour discovery
	[RFC6775] until it receives the necessary network configuration		[RFC6775] until it receives the necessary network configuration
	parameters. However, before the device can receive these		parameters. However, before the device can receive these
	configuration parameters, it may need to authenticate itself or wish		configuration parameters, it may need to authenticate itself or wish
	to authenticate the network to which it connects. DTLS although a		to authenticate the network to which it connects. Although DTLS is a
	suitable protocol for such authentication and secure transfer of		suitable protocol for such authentication and secure transfer of
	configuration parameters, would not work due to the lack of IP		configuration parameters, it would not work due to the lack of IP
	routability of DTLS messages between the intended recipients.		routability of DTLS messages between DTLS Client and DTLS Server.
	We present a DTLS Relay solution to overcome this problem for the		We present a DTLS Relay solution to overcome this problem for the
	"joining" device to establish a secure DTLS connection with a DTLS		"joining" device to establish a DTLS connection with a DTLS Server.
	server. This draft is inspired by the Protocol for carrying		This draft is inspired by the Protocol for carrying Authentication
	Authentication for Network Access (PANA) Relay Element [RFC6345]		for Network Access (PANA) Relay Element [RFC6345] which is intended
	which is intended to solve a similar problem when PANA [RFC5191] is		to solve a similar problem when PANA [RFC5191] is used as the
	used as the transport protocol for Extensible Authentication Protocol		transport protocol for Extensible Authentication Protocol (EAP)
	(EAP) [RFC3748] based network access. Recently there has been		[RFC3748] based network access. Recently there has been interest in
	interest in transporting EAP over CoAP		transporting EAP over CoAP
	[I-D.marin-ace-wg-coap-eap][I-D.ohba-core-eap-based-bootstrapping]		[I-D.marin-ace-wg-coap-eap][I-D.ohba-core-eap-based-bootstrapping]
	and presented DTLS Relay solution can be used to secure these		and presented DTLS Relay solution can be used to secure these
	messages. Further we present a stateful and stateless mode of		messages. Further, we present a stateful and stateless mode of
	operation for the DTLS Relay.		operation for the DTLS Relay.
	This draft is an early description of the solutions and does not		This draft is an early description of the solutions and does not
	provide the complete details yet. This draft is structured as		provide the complete details yet. This draft is structured as
	follows: we present a use-case for the DTLS Relay in Section 2, then		follows: we present a use-case for the DTLS Relay in Section 2, then
	present the DTLS Relay solution in Section 3 for stateful and		present the DTLS Relay solution in Section 3 for stateful and
	stateless mode of operation. We compare these two solutions in		stateless mode of operation. We compare these two solutions in
	Section 3.3. Further we present some security considerations in		Section 3.3. Further we present some security considerations in
	Section 5.		Section 5.
	2. Use Case		2. Use Case
	We present here a target usecase based on		We present here a target usecase based on
	[I-D.jennings-core-transitive-trust-enrollment] describing a		[I-D.jennings-core-transitive-trust-enrollment] describing a
	rendezvous protocol that allows a constrained IoT device to securely		rendezvous protocol that allows a constrained IoT device to securely
	connect into a system or network. The main idea is that the joining		connect into a system or network. The main idea is that the joining
	Device has a pre-established trust relationship with a "Transfer		Device has a pre-established trust relationship with a "Transfer
	Agent" entity, for e.g. Pre-Shared Keys provisioned during		Agent" entity, for e.g. Pre-Shared Keys provisioned during
	manufacturing. This "Transfer Agent" provides the needed trust		manufacturing. This "Transfer Agent" provides the needed trust
	credentials to the Device and/or a Controller in the system to		credentials to the Device and/or a Controller in the system to
	establish a secured connection to perform further authentication and		establish a secured connection to perform further authentication and
	transfer of system/network configuration parameters. This step is		transfer of system/network configuration parameters. This step is
	enabled by an "Introducer" entity which informs the "Transfer Agent"		enabled by an "Introducer" entity which informs the "Transfer Agent"
	about the details of Controller to which the joining Device should		about the details of Controller to which the joining Device should
	connect, and provide to the Controller the identity including one-		connect, and provide to the Controller the identity including one-
	time credentials for enable secure connection to the Device. The		time credentials for enable secure connection to the Device. The
	transitive trust trust establishment procedure is explained in detail		transitive trust trust establishment procedure is explained in detail
	in [I-D.jennings-core-transitive-trust-enrollment] and we focus here		in [I-D.jennings-core-transitive-trust-enrollment] and we focus here
	on how to enable this using DTLS.		on how to enable this using DTLS.
	As depicted in the Figure 1, the joining Device (D) is multi-hop away		As depicted in the Figure 1, the joining Device (D) is more than one
	from the Controller (C) and not yet authenticated into the network.		hop away from the Controller (C) and not yet authenticated into the
	At this stage, it can only communicate one-hop to its nearest		network. At this stage, it can only communicate one-hop to its
	neighbour (N) using their link-local IPv6 addresses. However, the		nearest neighbour (N) using their link-local IPv6 addresses.
	Device needs to communicate with end-to-end security with a Transfer		However, the Device needs to communicate with end-to-end security
	Agent (T) or to Controller (C) to authenticate and get the relevant		with a Transfer Agent (T) or a Controller (C) to authenticate and get
	system/network parameters. If the Device (D), initiates a DTLS		the relevant system/network parameters. If the Device (D) initiates
	connection to the Transfer Agent that has been pre-configured, then		a DTLS connection to the Transfer Agent whose IP address has been
	the packets are dropped at the neighbour (N) since the Device (D) is		pre-configured, then the packets are dropped at the neighbour (N)
	not yet admitted to the network or there is no IP-routability to		since the Device (D) is not yet admitted to the network or there is
	Device (D) for any returned messages.		no IP routability to Device (D) for any returned messages.
	Trust Agent		Transfer Agent
	++++		++++
	|T |		|T |
	| | +--+		| | +--+
	++++ |N'|		++++ |N'|
	| --+--+		| --+--+
	| ++++ /		| ++++ /
	| |C |---- +--+ +--+		| |C |---- +--+ +--+
	--| | \ |N |........|D |		--| | \ |N |........|D |
	++++ \-----| | | |		++++ \-----| | | |
	Controller +--+ +--+		Controller +--+ +--+
	Neighbour "join" Device		Neighbour "Joining" Device
	Figure 1: Use case depiction in a multi-hop network		Figure 1: Use case depiction in a multi-hop network
	Further the Device (D) may wish to establish a secure connection to		Furthermore, the Device (D) may wish to establish a secure connection
	the Controller (C) in the network assuming credentials are exchanged		to the Controller (C) in the network assuming appropriate credentials
	out-of-band, for e.g. a hash of the Device (D)'s raw public key could		are exchanged out-of-band, e.g. a hash of the Device (D)'s raw public
	be provided to the Controller (C). However, the Device (D) is		key could be provided to the Controller (C). However, the Device (D)
	unaware of the IP address of the Controller (C) to initiate a DTLS		is unaware of the IP address of the Controller (C) to initiate a DTLS
	connection and perform authentication.		connection and perform authentication with.
	To overcome these problems with non-routability of DTLS packets and/		To overcome these problems with non-routability of DTLS packets and/
	or discovery of the destination address of the DTLS server to		or discovery of the destination address of the DTLS Server to
	contact, we define a DTLS Relay solution. This DTLS Relay ability is		contact, we define a DTLS Relay solution. This DTLS Relay ability is
	configured into all authenticated devices in the network which may		configured into all authenticated devices in the network which may
	act as the Neighbour (N) device for newly joining nodes. The DTLS		act as the Neighbour (N) device for newly joining nodes. The DTLS
	Relay allows for relaying of the packets from the Neighbour (N) using		Relay allows for relaying of the packets from the Neighbour (N) using
	IP-routing to the intended DTLS server. Further, if the DTLS server		IP routing to the intended DTLS Server. Furthermore, if the DTLS
	address is not known to the joining Device (D), then messages are		Server address is not known to the joining Device (D), then messages
	delivered to a pre-configured DTLS server address (mostly the		are delivered to a pre-configured DTLS Server address (most likely
	Controller (C)) known to the DTLS Relay.		the Controller (C)) known to the DTLS Relay.
	3. DTLS relay		3. DTLS Relay
	In this section, we describe how the DTLS Relay functionality can be		In this section, we describe how the DTLS Relay functionality can be
	achieved. When a joining device as a client attempts a DTLS		achieved. When a joining device as a client attempts a DTLS
	connection (for example to a "Transfer Agent"), it uses its link-		connection (for example to a "Transfer Agent"), it uses its link-
	local IP address as its IP source address. This message is		local IP address as its IP source address. This message is
	transmitted one-hop to a neighbour node. Under normal circumstances,		transmitted one-hop to a neighbour node. Under normal circumstances,
	this message would be dropped at the neighbour node since the joining		this message would be dropped at the neighbour node since the joining
	device is not yet IP routable, or it is not yet authenticated to send		device is not yet IP routable or it is not yet authenticated to send
	messages through the network. However, if the neighbour device has		messages through the network. However, if the neighbour device has
	the DTLS Relay functionality enabled, it forwards DTLS messages to		the DTLS Relay functionality enabled, it relays the DTLS message to a
	specific servers. Additional security mechanisms need to exist to		specific DTLS Server. Additional security mechanisms need to exist
	prevent this forwarding functionality to be used by rogue nodes to		to prevent this relaying functionality being used by rogue nodes to
	bypass any network authentication procedures and are discussed in		bypass any network authentication procedures. These mechanisms are
	Section 5.		discussed in Section 5.
	The DTLS Relay can operate in two different modes: stateful and		The DTLS Relay can operate in two different modes: stateful and
	stateless. We present here both the methods, however for inter-		stateless. We present here both modes, however for inter-
	operability, only one of the modes should be mandated. Within each		operability, only one of the modes should be mandated. Within each
	mode, the DTLS Relay can further forward packets based on the client		mode, the DTLS Relay can further relay packets based on the client-
	defined DTLS server address or a DTLS server address that has been		defined DTLS Server address or a DTLS Server address that has been
	configured into the Relay.		configured into the DTLS Relay.
	3.1. Relay in Stateful mode		3.1. DTLS Relay in Stateful mode
	The neighbour node on receiving a DTLS message from a joining device		On receiving a DTLS message from a joining device, the neighbour node
	enters into DTLS Relay mode. In this mode, the neighbour node has		enters into DTLS Relay stateful mode. In this mode, the neighbour
	the additional functionality to send DTLS messages further to the		node has the additional DTLS Relay functionality to send DTLS
	end-point DTLS server the joining device wishes to contact. In the		messages further to the end-point DTLS Server the joining device
	stateful mode of operation, the message is transmitted to the end-		wishes to contact. In the stateful mode of operation, the message is
	point as originating from the DTLS Relay by replacing the IP address		transmitted to the end-point DTLS Server as if it originated from the
	and port to DTLS Relay's own IP address and a randomly chosen port.		DTLS Relay, by replacing the IP address and port to the DTLS Relay's
	The DTLS message itself is not modified.		own IP address and a randomly chosen port. The DTLS message itself
			is not modified.
	Additionally, the DTLS Relay must track the ongoing DTLS connections		Additionally, the DTLS Relay must track the ongoing DTLS connections
	based on the following 4-tuple stored locally:		based on the following 4-tuple stored locally:
	o Client source IP address (IP_C)		o DTLS Client source link-local IP address (IP_C)
	o Client source port (p_C)		o DTLS Client source port (p_C)
	o DTLS Server IP address (IP_S)		o DTLS Server IP address (IP_S)
	o Relay source port (p_R)		o DTLS Relay source port (p_R)
	The DTLS server communicates to the Relay as if it were communicating		The DTLS Server communicates with the DTLS Relay as if it were
	to the end-point Client with no modification required to the DTLS		communicating with the DTLS Client, without any modification required
	messages. The Relay on receiving this message, looks up its locally		to the DTLS messages. On receiving a DTLS message from the DTLS
	stored 4-tuple array to identify to which joining device (if multiple		Server, the DTLS Relay looks up its locally stored 4-tuple array to
	exists) the message belongs. The DTLS message's destination address		identify to which DTLS Client (if multiple exist) the message
	is replaced with that of the link-local address and port of the		belongs. The DTLS message's destination address and port are
	joining device from the lookup array and forwarded to it. The Relay		replaced with the link-local address and port of the corresponding
	does not modify the DTLS packets and therefore the normal processing		DTLS Client respectively and the DTLS message is then forwarded to
	and security of DTLS is unaffected.		the DTLS Client. The DTLS Relay does not modify the DTLS packets and
			therefore the normal processing and security of DTLS is unaffected.
	The following message flow diagram indicates the various steps of the		The following message flow diagram indicates the various steps of the
	process where the DTLS server address in known to the joining device:		process where the DTLS Server address in known to the joining device:
	+---------------+---------------+----------------+---------------------------+		+---------------+---------------+----------------+---------------------------+
	| DTLS Client | DTLS Relay | DTLS Server | Message |		| DTLS Client | DTLS Relay | DTLS Server | Message |
	| (C) | (R) | (S) | Src_IP:port | Dst_IP:port |		| (C) | (R) | (S) | Src_IP:port | Dst_IP:port |
	+---------------+---------------+----------------+-------------+-------------+		+---------------+---------------+----------------+-------------+-------------+
	| --ClientHello--> | IP_C:p_C | IP_S:5684 |		| --ClientHello--> | IP_C:p_C | IP_S:5684 |
	| --ClientHello--> | IP_R:p_R | IP_S:5684 |		| --ClientHello--> | IP_R:p_R | IP_S:5684 |
	| | | |		| | | |
	| <--ServerHello-- | IP_S:5684 | IP_R:p_R |		| <--ServerHello-- | IP_S:5684 | IP_R:p_R |
	| : | | |		| : | | |
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 25 ¶
	| : | | |		| : | | |
	| :: | : | : |		| :: | : | : |
	| :: | : | : |		| :: | : | : |
	| --Finished--> | IP_C:p_C | IP_S:5684 |		| --Finished--> | IP_C:p_C | IP_S:5684 |
	| --Finished--> | IP_R:p_R | IP_S:5684 |		| --Finished--> | IP_R:p_R | IP_S:5684 |
	| | | |		| | | |
	| <--Finished-- | IP_S:5684 | IP_R:p_R |		| <--Finished-- | IP_S:5684 | IP_R:p_R |
	| <--Finished-- | IP_S:5684 | IP_C:p_C |		| <--Finished-- | IP_S:5684 | IP_C:p_C |
	| :: | : | : |		| :: | : | : |
	+------------------------------------------------+-------------+-------------+		+------------------------------------------------+-------------+-------------+
	IP_C:p_C = IP (non-routable) and port of Client		IP_C:p_C = Link-local IP address and port of DTLS Client
	IP_S:5684 = IP and coaps port of Server		IP_S:5684 = IP address and coaps port of DTLS Server
	IP_R:p_R = IP and port of Relay		IP_R:p_R = IP address and port of DTLS Relay
	Figure 2: Message flow in Stateful mode with DTLS Server defined by		Figure 2: Message flow in Stateful mode with DTLS Server defined by
	Client		DTLS Client
	In the situation where the joining device is unaware of the IP		In the situation where the joining device is unaware of the IP
	address of DTLS server it needs to contact, for e.g. the Controller		address of the DTLS Server it needs to contact, for e.g. the
	of the network, the DTLS Relay can be configured with IP destination		Controller of the network, the DTLS Relay can be configured with IP
	of the default DTLS server that a joining device needs to contact.		destination of the default DTLS Server that a DTLS client (joining
	The joining device initiates its DTLS request as if the DTLS Relay is		device) needs to contact. The DTLS client initiates its DTLS request
	the intended end-point DTLS server. The DTLS relay translates the		as if the DTLS Relay is the intended end-point DTLS Server. The DTLS
	DTLS message as in the previous case by modifying both the source and		Relay changes the IP packet (without modifying the DTLS message) as
	destination IP address to forward the message to the intended DTLS		in the previous case by modifying both the source and destination IP
	server. The Relay keeps a similar 4-tuple array to enable		addresses to forward the message to the intended DTLS Server. The
	translation of the DTLS messages received from the server and forward		DTLS Relay keeps a similar 4-tuple array to enable translation of the
	it to the DTLS Client. The following message flow indicates this		DTLS messages received from the DTLS Server and forward it to the
	process:		DTLS Client. The following message flow indicates this process:
	+---------------+---------------+----------------+---------------------------+		+---------------+---------------+----------------+---------------------------+
	| DTLS Client | DTLS Relay | DTLS Server | Message |		| DTLS Client | DTLS Relay | DTLS Server | Message |
	| (C) | (R) | (S) | Src_IP:port | Dst_IP:port |		| (C) | (R) | (S) | Src_IP:port | Dst_IP:port |
	+---------------+---------------+----------------+-------------+-------------+		+---------------+---------------+----------------+-------------+-------------+
	| --ClientHello--> | IP_C:p_C | IP_Ra:5684 |		| --ClientHello--> | IP_C:p_C | IP_Ra:5684 |
	| --ClientHello--> | IP_Rb:p_Rb| IP_S:5684 |		| --ClientHello--> | IP_Rb:p_Rb| IP_S:5684 |
	| | | |		| | | |
	| <--ServerHello-- | IP_S:5684 | IP_Rb:p_Rb |		| <--ServerHello-- | IP_S:5684 | IP_Rb:p_Rb |
	| : | | |		| : | | |
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 25 ¶
	| : | | |		| : | | |
	| :: | : | : |		| :: | : | : |
	| :: | : | : |		| :: | : | : |
	| --Finished--> | IP_C:p_C | IP_Ra:5684 |		| --Finished--> | IP_C:p_C | IP_Ra:5684 |
	| --Finished--> | IP_Rb:p_Rb| IP_S:5684 |		| --Finished--> | IP_Rb:p_Rb| IP_S:5684 |
	| | | |		| | | |
	| <--Finished-- | IP_S:5684 | IP_Rb:p_Rb |		| <--Finished-- | IP_S:5684 | IP_Rb:p_Rb |
	| <--Finished-- | IP_Ra:5684| IP_C:p_C |		| <--Finished-- | IP_Ra:5684| IP_C:p_C |
	| :: | : | : |		| :: | : | : |
	+------------------------------------------------+-------------+-------------+		+------------------------------------------------+-------------+-------------+
	IP_C:p_C = IP (non-routable) and port of Client		IP_C:p_C = Link-local IP address and port of DTLS Client
	IP_S:5684 = IP and coaps port of Server		IP_S:5684 = IP address and coaps port of DTLS Server
	IP_Ra:5684 = IP and coaps port of Relay		IP_Ra:5684 = Link-local IP address and coaps port of DTLS Relay
	IP_Rb:p_Rb = IP (can be same as IP_Ra) and the port of Relay		IP_Rb:p_Rb = IP address (can be same as IP_Ra) and port of DTLS Relay
	Figure 3: Message flow in Stateful mode with DTLS Server defined by		Figure 3: Message flow in Stateful mode with DTLS Server defined by
	Relay		DTLS Relay
	3.2. Relay in Stateless mode		3.2. DTLS Relay in Stateless mode
	In the alternative mode of operation for the DTLS Relay, a stateless		In the alternative mode of operation for the DTLS Relay, a stateless
	approach is applied where th Relay does not need to store a local		approach is applied where the DTLS Relay does not need to store a
	4-tuple array. Just as in the previous case, if a DTLS client with		local 4-tuple array. Just as in the previous case, if an untrusted
	only link local addressing wants to contact a trusted end-point DTLS		DTLS Client that can only use link-local addressing wants to contact
	server, it send the DTLS message to the Relay. The Relay instead of		a trusted end-point DTLS Server, it send the DTLS message to the DTLS
	translating, encapsulates this message into a new type of message		Relay. Instead of changing the IP addresses and port of the IP
	called DTLS Relay (DRY) message. The DRY consists of two parts:		packet, the DTLS Relay encapsulates this message into a new type of
			message called DTLS Relay (DRY) message. The DRY message consists of
			two parts:
	o Header (H) field: consisting of the source link-local address and		o Header (H) field: consisting of the source link-local address and
	port of the DTLS Client device, and		port of the DTLS Client device, and
	o Contents (C) field: containing the original DTLS message.		o Contents (C) field: containing the original DTLS message.
	The DTLS end server on receiving the DRY message, decapsulates it to		On receiving the DRY message, the DTLS Server decapsulates it to
	retrieve the two parts. It then uses the Header field information to		retrieve the two parts. It uses the Header field information to
	associate the new state created on the server for the DTLS connection		transiently store the DTLS Client's address and port. The DTLS
	to the DTLS client's address and port. The DTLS server then performs		Server then performs the normal DTLS operations on the DTLS message
	the normal DTLS operations on the DTLS message contents. However		from the Contents field. However, when the DTLS Server replies, it
	when the DTLS server replies, it also encapsulates its message in a		also encapsulates its DTLS message in a DRY message back to the DTLS
	DRY message back to the Relay with the Header containing the original		Relay. The Header contains the original source link-local address
	source link-local address and port of the DTLS Client. The Relay can		and port of the DTLS Client from the transient state stored earlier
	decapsulate the DRY message, retrieves the Header information to		(which can now be discarded) and the Contents field contains the DTLS
	forward this message to the right DTLS Client device.		message.
			On receiving the DRY message, the DTLS Relay decapsulates it to
			retrieve the two parts. It uses the Header field to relay the DTLS
			message retrieved from the Contents field to the right DTLS Client.
	The following figure depicts the message flow diagram when the DTLS		The following figure depicts the message flow diagram when the DTLS
	server end-point address is known only to the Relay:		Server end-point address is known only to the Relay:
	+----------------+---------------------+---------------------+---------------------------+		+----------------+---------------------+---------------------+---------------------------+
	| DTLS Client | DTLS Relay | DTLS Server | Message |		| DTLS Client | DTLS Relay | DTLS Server | Message |
	| (C) | (R) | (S) | Src_IP:port | Dst_IP:port |		| (C) | (R) | (S) | Src_IP:port | Dst_IP:port |
	+----------------+---------------------+---------------------+-------------+-------------+		+----------------+---------------------+---------------------+-------------+-------------+
	| --ClientHello--> | IP_C:p_C | IP_Ra:5684 |		| --ClientHello--> | IP_C:p_C | IP_Ra:5684 |
	| --DRY[H(IP_C:p_C),C(ClientHello)]--> | IP_Rb:p_Rb| IP_S:5684 |		| --DRY[H(IP_C:p_C),C(ClientHello)]--> | IP_Rb:p_Rb| IP_S:5684 |
	| | | |		| | | |
	| <--DRY[H(IP_C:p_C),C(ServerHello)]-- | IP_S:5684 | IP_Rb:p_Rb |		| <--DRY[H(IP_C:p_C),C(ServerHello)]-- | IP_S:5684 | IP_Rb:p_Rb |
	| : | | |		| : | | |
	skipping to change at page 9, line 34 ¶		skipping to change at page 9, line 40 ¶
	| : | | |		| : | | |
	| :: | : | : |		| :: | : | : |
	| :: | : | : |		| :: | : | : |
	| --Finished--> | IP_C:p_C | IP_Ra:5684 |		| --Finished--> | IP_C:p_C | IP_Ra:5684 |
	| --DRY[H(IP_C:p_C),C(Finished)]--> | IP_Rb:p_Rb| IP_S:5684 |		| --DRY[H(IP_C:p_C),C(Finished)]--> | IP_Rb:p_Rb| IP_S:5684 |
	| | | |		| | | |
	| <--DRY[H(IP_C:p_C),C(Finished)]-- | IP_S:5684 | IP_Rb:p_Rb |		| <--DRY[H(IP_C:p_C),C(Finished)]-- | IP_S:5684 | IP_Rb:p_Rb |
	| <--Finished-- | IP_Ra:5684| IP_C:p_C |		| <--Finished-- | IP_Ra:5684| IP_C:p_C |
	| :: | : | : |		| :: | : | : |
	+------------------------------------------------------------+-------------+-------------+		+------------------------------------------------------------+-------------+-------------+
	IP_C:p_C = IP (non-routable) and port of Client		IP_C:p_C = Link-local IP address and port of DTLS Client
	IP_S:5684 = IP and coaps port of Server		IP_S:5684 = IP address and coaps port of DTLS Server
	IP_Ra:5684 = IP and coaps port of Relay		IP_Ra:5684 = Link-local IP address and coaps port of DTLS Relay
	IP_Rb:p_Rb = IP (can be same as IP_Ra) and the port of Relay		IP_Rb:p_Rb = IP address(can be same as IP_Ra) and port of DTLS Relay
	DRY[H(),C()] = DTLS Relay message with header H and content C		DRY[H(),C()] = DTLS Relay message with header H and content C
	Figure 4: Message flow in Stateless mode with DTLS Server defined by		Figure 4: Message flow in Stateless mode with DTLS Server defined by
	Relay		DTLS Relay
	The message flow for the case in which the DTLS Client is aware of		The message flow for the case in which the DTLS Client is aware of
	the end-point DTLS server's address is similar and not described		the end-point DTLS Server's IP address is similar and not described
	further. It can be derived based on Figure 2 and Figure 4.		further. It can be derived based on Figure 2 and Figure 4.
	3.3. Comparison between the two modes		3.3. Comparison between the two modes
	The stateful and stateless mode of operation for the DTLS Relay have		The stateful and stateless mode of operation for the DTLS Relay have
	their advantages and disadvantages. This comparison should enable to		their advantages and disadvantages. This comparison should enable to
	make a good choice between the two based on the available device		make a good choice between the two based on the available device
	resources and network bandwidth in a given deployment.		resources and network bandwidth in a given deployment.
	+-------------------+-----------------------------------+--------------------------------+		+-------------------+-----------------------------------+--------------------------------+
	skipping to change at page 10, line 46 ¶		skipping to change at page 11, line 7 ¶
	4. IANA Considerations		4. IANA Considerations
	tbd		tbd
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	5. Security Considerations		5. Security Considerations
	Additional security considerations need to be taken into account		Additional security considerations need to be taken into account when
	about forwarding of messages from devices through a network to which		forwarding messages from devices through a network to which it has
	it has not yet been admitted. This can lead to denial-of-service		not yet been admitted since this can lead to denial-of-service (DoS)
	attacks or misuse of network resources without proper authentication.		attacks or misuse of network resources without proper authentication.
	One way to overcome any large scale misuse of the network is to have		There are various solution options by which one could try to limit
	a management message from the Controller that initiates already		the damage that an attacker can cause by DoS. One way to overcome
	authenticated devices in the network to enter into a DTLS Relay mode.		any large scale misuse of the network is to have a management message
	The devices can stay such a Relay mode for a fixed period of time or		from the Controller that initiates already authenticated devices in
	until the Controller sends a new management message blocking the DTLS		the network to enable or disable the DTLS Relay mode. This is often
	Relay mode in all devices in the network. This is often possible		possible since the administrator of the network is aware when new
	since the administrator of the network can be aware when new devices		devices join the network either because of the "Introduction" phase
	join the network either because of the "Introduction" phase or		or commissioning phase. Alternatively the management message can be
	commissioning phase.		used to control a different networking layer on the relay nodes that
			disable new nodes from joining. Such solution options are orthogonal
			to the DTLS relay functionality and should be built in based on the
			underlying network capabilities and deployment scenario.
	Other mechanisms based on IP destination filtering can be applied by		In terms of the two different modes, Stateful mode has additional
	the controller to all Relay nodes to avoid misuse of the network		security issues since the DTLS Relay has to store state from an
	resources.		unauthenticated node and then relay a message, expecting a
			corresponding reply sometime in the future. Furthermore, the DTLS
			Server has to store state as well but it is more transient. This
			could lead to a simple localised attack on a DTLS Relay whereby a
			rogue device could use up state storage on a DTLS Relay quite easily,
			thus denying a legitimate device from being able to gain access.
			In comparison, in the Stateless mode the DTLS Relay does not store
			any state, and therefore an attack as described above is not
			possible. Also a DTLS Server can legitimately silently discard a
			DTLS message without concern as the DTLS Relay has no further
			knowledge or state stored of the DTLS Client. The DTLS cookie
			mechanism is a good addition to a stateless transaction which
			improves the likelihood a DTLS Server is talking to a genuine DTLS
			Client.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank Sahil Sharma, Ernest Ma, Dee		The authors would like to thank Sahil Sharma, Ernest Ma, Dee
	Denteneer and Peter Lenoir for the valuable discussions and		Denteneer, Peter Lenoir and Martin Turon for the valuable
	suggestions,		discussions. Also thank Robert Craige for his valuable comments and
			edits.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.		Security Version 1.2", RFC 6347, January 2012.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-core-coap]
	Shelby, Z., Hartke, K., and C. Bormann, "Constrained
	Application Protocol (CoAP)", draft-ietf-core-coap-18
	(work in progress), June 2013.
	[I-D.jennings-core-transitive-trust-enrollment]		[I-D.jennings-core-transitive-trust-enrollment]
	Jennings, C., "Transitive Trust Enrollment for Constrained		Jennings, C., "Transitive Trust Enrollment for Constrained
	Devices", draft-jennings-core-transitive-trust-		Devices", draft-jennings-core-transitive-trust-
	enrollment-01 (work in progress), October 2012.		enrollment-01 (work in progress), October 2012.
	[I-D.marin-ace-wg-coap-eap]		[I-D.marin-ace-wg-coap-eap]
	Lopez, R. and R. Sanchez, "EAP-based Authentication		Garcia, D., "EAP-based Authentication Service for CoAP",
	Service for CoAP", draft-marin-ace-wg-coap-eap-00 (work in		draft-marin-ace-wg-coap-eap-01 (work in progress), October
	progress), April 2014.		2014.
	[I-D.ohba-core-eap-based-bootstrapping]		[I-D.ohba-core-eap-based-bootstrapping]
	Das, S. and Y. Ohba, "Provisioning Credentials for CoAP		Das, S. and Y. Ohba, "Provisioning Credentials for CoAP
	Applications using EAP", draft-ohba-core-eap-based-		Applications using EAP", draft-ohba-core-eap-based-
	bootstrapping-01 (work in progress), March 2012.		bootstrapping-01 (work in progress), March 2012.
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	August 1980.		August 1980.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
	skipping to change at page 12, line 35 ¶		skipping to change at page 13, line 10 ¶
	[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A.		[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A.
	Yegin, "Protocol for Carrying Authentication for Network		Yegin, "Protocol for Carrying Authentication for Network
	Access (PANA) Relay Element", RFC 6345, August 2011.		Access (PANA) Relay Element", RFC 6345, August 2011.
	[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,		[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
	"Neighbor Discovery Optimization for IPv6 over Low-Power		"Neighbor Discovery Optimization for IPv6 over Low-Power
	Wireless Personal Area Networks (6LoWPANs)", RFC 6775,		Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
	November 2012.		November 2012.
			[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
			Constrained-Node Networks", RFC 7228, May 2014.
			[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
			Application Protocol (CoAP)", RFC 7252, June 2014.
	[ieee802.15.4]		[ieee802.15.4]
	IEEE Computer Society, , "IEEE Std. 802.15.4-2003",		IEEE Computer Society, , "IEEE Std. 802.15.4-2003",
	October 2003.		October 2003.
	Authors' Addresses		Authors' Addresses
	Sandeep S. Kumar		Sandeep S. Kumar (editor)
	Philips Research		Philips Research
	High Tech Campus 34		High Tech Campus 34
	Eindhoven 5656 AE		Eindhoven 5656 AE
	NL		NL
	Email: sandeep.kumar@philips.com		Email: ietf@sandeep.de
	Sye Loong Keoh		Sye Loong Keoh
	University of Glasgow Singapore		University of Glasgow Singapore
	Republic PolyTechnic, 9 Woodlands Ave 9		Republic PolyTechnic, 9 Woodlands Ave 9
	Singapore 838964		Singapore 838964
	SG		SG
	Email: SyeLoong.Keoh@glasgow.ac.uk		Email: SyeLoong.Keoh@glasgow.ac.uk
	Oscar Garcia-Morchon		Oscar Garcia-Morchon
	Philips Research		Philips Research
End of changes. 56 change blocks.
	197 lines changed or deleted		226 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/