< draft-kumar-dice-dtls-relay-00.txt   draft-kumar-dice-dtls-relay-01.txt >
DICE Working Group S. Kumar DICE Working Group S. Kumar
Internet-Draft Philips Research Internet-Draft Philips Research
Intended status: Standards Track S. Keoh Intended status: Standards Track S. Keoh
Expires: April 24, 2014 University of Glasgow Singapore Expires: October 24, 2014 University of Glasgow Singapore
O. Garcia-Morchon O. Garcia-Morchon
Philips Research Philips Research
October 21, 2013 April 22, 2014
DTLS Relay for Constrained Environments DTLS Relay for Constrained Environments
draft-kumar-dice-dtls-relay-00 draft-kumar-dice-dtls-relay-01
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. the 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. This prevents "joining" device may not be initially IP routable until it is
DTLS from being directly useful as an authentication and authenticated to the network. This prevents DTLS from being directly
confidentiality protocol during this stage, requiring other security useful as an authentication and confidentiality protocol during this
protocols to be implemented on the device. These devices being stage, requiring other security protocols to be implemented on the
resource-constrained often cannot accommodate more than one security device. These devices being resource-constrained often cannot
protocol in their code memory. To overcome this problem and reuse accommodate more than one security protocol in their code memory. To
DTLS, we present a DTLS Relay solution for the non-IP routable overcome this problem and reuse DTLS, we present a DTLS Relay
"joining" device to establish a secure DTLS connection with a DTLS solution for the non-IP routable "joining" device to establish a
server. Further we present a stateful and stateless mode of secure DTLS connection with a DTLS server. Further we present a
operation for the DTLS Relay. 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 24, 2014. This Internet-Draft will expire on October 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DTLS relay . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. DTLS relay . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Relay in Stateful mode . . . . . . . . . . . . . . . . . 5 3.1. Relay in Stateful mode . . . . . . . . . . . . . . . . . 6
3.2. Relay in Stateless mode . . . . . . . . . . . . . . . . . 7 3.2. Relay in Stateless mode . . . . . . . . . . . . . . . . . 8
3.3. Comparison between the two modes . . . . . . . . . . . . 9 3.3. Comparison between the two modes . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Internet-of-Things (IoTs) vision is more closer to reality with The Internet-of-Things (IoTs) vision is more closer to reality with
the IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) the IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN)
[RFC4944] and Constrained Application Protocol (CoAP) [RFC4944] and Constrained Application Protocol (CoAP)
[I-D.ietf-core-coap] standards . The 6LoWPAN adaptation layer allows [I-D.ietf-core-coap] standards . The 6LoWPAN adaptation layer allows
for transmission of IPv6 Packets over IEEE 802.15.4 networks for transmission of IPv6 Packets over IEEE 802.15.4 networks
[ieee802.15.4] and thereby enabling end-to-end IPv6 connectivity of [ieee802.15.4] and thereby enabling end-to-end IPv6 connectivity of
"Things". CoAP is a web protocol based on REST architecture designed "Things". CoAP is a web protocol based on REST architecture designed
skipping to change at page 3, line 21 skipping to change at page 3, line 21
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 point-to-point 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. A new "joining" device can only initially be initially IP routable until it is authenticated to the network. A
use a link-local IPv6 address to communicate with a neighbour node new "joining" device can only initially use a link-local IPv6 address
using neighbour discovery [RFC6775] until it receives the necessary to communicate with a neighbour node using neighbour discovery
network configuration parameters. Before the device can receive [RFC6775] until it receives the necessary network configuration
these configuration parameters, it may need to authenticate itself or parameters. However, before the device can receive these
wish to authenticate the network to which it connects. DTLS although configuration parameters, it may need to authenticate itself or wish
a suitable protocol for such authentication and secure transfer of to authenticate the network to which it connects. DTLS although a
suitable protocol for such authentication and secure transfer of
configuration parameters, would not work due to the lack of IP configuration parameters, would not work due to the lack of IP
routability of its messages to the intended recipients. routability of DTLS messages between the intended recipients.
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 secure DTLS connection with a DTLS
server. This draft is inspired by the Protocol for carrying server. This draft is inspired by the Protocol for carrying
Authentication for Network Access (PANA) Relay Element [RFC6345] Authentication for Network Access (PANA) Relay Element [RFC6345]
which is intended to solve a similar problem when PANA [RFC5191] is which is intended to solve a similar problem when PANA [RFC5191] is
used for network access. Further we present a stateful and stateless used as the transport protocol for Extensible Authentication Protocol
mode of operation for the DTLS Relay. (EAP) [RFC3748] based network access. Recently there has been
interest in transporting EAP over CoAP
[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
messages. Further we present a stateful and stateless mode of
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. Further we present some security stateless mode of operation. We compare these two solutions in
considerations in Section 5. Section 3.3. Further we present some security considerations in
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
skipping to change at page 4, line 30 skipping to change at page 5, line 5
At this stage, it can only communicate one-hop to its nearest At this stage, it can only communicate one-hop to its nearest
neighbour (N) using their link-local IPv6 addresses. However, the neighbour (N) using their link-local IPv6 addresses. However, the
Device needs to communicate with end-to-end security with a Transfer Device needs to communicate with end-to-end security with a Transfer
Agent (T) or to Controller (C) to authenticate and get the relevant Agent (T) or to Controller (C) to authenticate and get the relevant
system/network parameters. If the Device (D), initiates a DTLS system/network parameters. If the Device (D), initiates a DTLS
connection to the Transfer Agent that has been pre-configured, then connection to the Transfer Agent that has been pre-configured, then
the packets are dropped at the neighbour (N) since the Device (D) is the packets are dropped at the neighbour (N) since the Device (D) is
not yet admitted to the network or there is no IP-routability to not yet admitted to the network or there is no IP-routability to
Device (D) for any returned messages. Device (D) for any returned messages.
Trust Agent Trust Agent
++++ ++++
|T | |T |
| | +--+ | | +--+
++++ |N'| ++++ |N'|
| --+--+ | --+--+
| ++++ / | ++++ /
| |C |---- +--+ +--+ | |C |---- +--+ +--+
--| | \ |N |........|D | --| | \ |N |........|D |
++++ \-----| | | | ++++ \-----| | | |
Controller +--+ +--+ Controller +--+ +--+
Neighbour "join" Device Neighbour "join" 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 Further the Device (D) may wish to establish a secure connection to
the Controller (C) in the network assuming credentials are exchanged the Controller (C) in the network assuming credentials are exchanged
out-of-band, for e.g. a hash of the Device (D)'s raw public key could out-of-band, for e.g. a hash of the Device (D)'s raw public key could
be provided to the Controller (C). However, the Device (D) is be provided to the Controller (C). However, the Device (D) is
unaware of the IP address of the Controller (C) to initiate a DTLS unaware of the IP address of the Controller (C) to initiate a DTLS
connection and perform authentication. connection and perform authentication.
skipping to change at page 6, line 29 skipping to change at page 7, line 5
stored 4-tuple array to identify to which joining device (if multiple stored 4-tuple array to identify to which joining device (if multiple
exists) the message belongs. The DTLS message's destination address exists) the message belongs. The DTLS message's destination address
is replaced with that of the link-local address and port of the is replaced with that of the link-local address and port of the
joining device from the lookup array and forwarded to it. The Relay joining device from the lookup array and forwarded to it. The Relay
does not modify the DTLS packets and therefore the normal processing does not modify the DTLS packets and therefore the normal processing
and security of DTLS is unaffected. 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 |
| : | | | | : | | |
| <--ServerHello-- | IP_S:5684 | IP_C:p_C | | <--ServerHello-- | IP_S:5684 | IP_C:p_C |
| : | | | | : | | |
| :: | : | : | | :: | : | : |
| :: | : | : | | :: | : | : |
| --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 = IP (non-routable) and port of Client
IP_S:5684 = IP and coaps port of Server IP_S:5684 = IP and coaps port of Server
IP_R:p_R = IP and port of Relay IP_R:p_R = IP and port of 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 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 DTLS server it needs to contact, for e.g. the Controller
of the network, the DTLS Relay can be configured with IP destination of the network, the DTLS Relay can be configured with IP destination
of the default DTLS server that a joining device needs to contact. of the default DTLS server that a joining device needs to contact.
The joining device initiates its DTLS request as if the DTLS Relay is The joining device initiates its DTLS request as if the DTLS Relay is
the intended end-point DTLS server. The DTLS relay translates the the intended end-point DTLS server. The DTLS relay translates the
DTLS message as in the previous case by modifying both the source and DTLS message as in the previous case by modifying both the source and
destination IP address to forward the message to the intended DTLS destination IP address to forward the message to the intended DTLS
server. The Relay keeps a similar 4-tuple array to enable server. The Relay keeps a similar 4-tuple array to enable
translation of the DTLS messages received from the server and forward translation of the DTLS messages received from the server and forward
it to the DTLS Client. The following message flow indicates this it to the DTLS Client. The following message flow indicates this
process: 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 |
| : | | | | : | | |
| <--ServerHello-- | IP_Ra:5684| IP_C:p_C | | <--ServerHello-- | IP_Ra:5684| IP_C:p_C |
| : | | | | : | | |
| :: | : | : | | :: | : | : |
| :: | : | : | | :: | : | : |
| --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 = IP (non-routable) and port of Client
IP_S:5684 = IP and coaps port of Server IP_S:5684 = IP and coaps port of Server
IP_Ra:5684 = IP and coaps port of Relay IP_Ra:5684 = IP and coaps port of Relay
IP_Rb:p_Rb = IP (can be same as IP_Ra) and the port of Relay IP_Rb:p_Rb = IP (can be same as IP_Ra) and the port of 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 Relay
3.2. Relay in Stateless mode 3.2. 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 th Relay does not need to store a local
4-tuple array. Just as in the previous case, if a DTLS client with 4-tuple array. Just as in the previous case, if a DTLS client with
only link local addressing wants to contact a trusted end-point DTLS only link local addressing wants to contact a trusted end-point DTLS
server, it send the DTLS message to the Relay. The Relay instead of server, it send the DTLS message to the Relay. The Relay instead of
translating, encapsulates this message into a new type of message translating, encapsulates this message into a new type of message
called DTLS Relay (DRY) message. The DRY consists of two parts: called DTLS Relay (DRY) message. The DRY 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
skipping to change at page 8, line 31 skipping to change at page 9, line 14
the normal DTLS operations on the DTLS message contents. However the normal DTLS operations on the DTLS message contents. However
when the DTLS server replies, it also encapsulates its message in a when the DTLS server replies, it also encapsulates its message in a
DRY message back to the Relay with the Header containing the original DRY message back to the Relay with the Header containing the original
source link-local address and port of the DTLS Client. The Relay can source link-local address and port of the DTLS Client. The Relay can
decapsulate the DRY message, retrieves the Header information to decapsulate the DRY message, retrieves the Header information to
forward this message to the right DTLS Client device. forward this message to the right DTLS Client device.
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 |
| : | | | | : | | |
| <--ServerHello-- | IP_Ra:5684| IP_C:p_C | | <--ServerHello-- | IP_Ra:5684| IP_C:p_C |
| : | | | | : | | |
| :: | : | : | | :: | : | : |
| :: | : | : | | :: | : | : |
| --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 = IP (non-routable) and port of Client
IP_S:5684 = IP and coaps port of Server IP_S:5684 = IP and coaps port of Server
IP_Ra:5684 = IP and coaps port of Relay IP_Ra:5684 = IP and coaps port of Relay
IP_Rb:p_Rb = IP (can be same as IP_Ra) and the port of Relay IP_Rb:p_Rb = IP (can be same as IP_Ra) and the port of 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 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 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
A comparison between the two modes will be done in an updated version The stateful and stateless mode of operation for the DTLS Relay have
of this draft. their advantages and disadvantages. This comparison should enable to
make a good choice between the two based on the available device
resources and network bandwidth in a given deployment.
+-------------------+-----------------------------------+--------------------------------+
| Properties | Stateful mode | Stateless mode |
+-------------------+-----------------------------------+--------------------------------+
| State information |The Relay needs additional storage | No information is maintained by|
| |to maintain mapping of the joining | the Relay. |
| |device's address with the port | |
| |number being used to communicate | |
| |with the Server. | |
+-------------------+-----------------------------------+--------------------------------+
| Packet size |The size of the relayed message is |The size of the relayed message|
| |the same as the original message . |is bigger than the original, it |
| | |includes additional source and |
| | |destination addresses. |
+-------------------+-----------------------------------+--------------------------------+
| Standardization |The additional functionalities of |New DRY message to encapsulate |
| requirements |the Relay to maintain state |DTLS message. The Server and the|
| |information, and modify the source |Relay have to understand the DRY|
| |and destination addresses of the |message in order to process it. |
| |DTLS handshake messages. | |
+-------------------+-----------------------------------+--------------------------------+
Table 1: Comparison between stateful and stateless mode DTLS Relay
Figure 5
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
skipping to change at page 10, line 30 skipping to change at page 11, line 42
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18 Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013. (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]
Lopez, R. and R. Sanchez, "EAP-based Authentication
Service for CoAP", draft-marin-ace-wg-coap-eap-00 (work in
progress), April 2014.
[I-D.ohba-core-eap-based-bootstrapping]
Das, S. and Y. Ohba, "Provisioning Credentials for CoAP
Applications using EAP", draft-ohba-core-eap-based-
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
793, September 1981. 793, September 1981.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008. Access (PANA)", RFC 5191, May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
skipping to change at page 11, line 8 skipping to change at page 12, line 36
[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.
[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
Philips Research Philips Research
High Tech Campus 34 High Tech Campus 34
Eindhoven 5656 AE Eindhoven 5656 AE
NL NL
 End of changes. 22 change blocks. 
125 lines changed or deleted 175 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/