Subject: [Dtls-iot] Constrained Server (again)

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Dec 2014 10:35:37 +0100

I have tried to come up with some text for the constrained server case
and I am wondering whether it addresses the comments raised earlier (or
are we are talking past each other).

------

4. Constrained Servers

When a constrained client uploads sensor data to a server infrastructure
it may use CoAP by pushing the data via a POST to a pre-configured
endpoint on the server. In certain circumstances this might be too
limiting and additional functionality is needed, as shown in Figure 1.

Figure 1 shows a sensor starting with a DTLS exchange with a resource
server to register available resources. The initial DTLS interaction
between the sensor, acting as a DTLS client, and the resource server,
acting as a DTLS server, will be a full DTLS handshake. Once this
handshake is complete both parties have established the DTLS record
layer, which can subsequently be used to secure the CoAP message
exchange, which starts with a the resource registration. Details about
the resource registry capabilities can be found in
[I-D.ietf-core-resource-directory].

After some time (assuming that the client regularly refreshes its
registration) the resource server receives a request (not shown) from an
application to retrieve the temperature information from the sensor.
This request is relayed by the resource directory to the sensor using a
GET message exchange. The already established DTLS record layer can be
used to secure the message exchange.

                                                 Resource
    Sensor                                       Directory
    ------                                       ---------

  +---
  |
  | ClientHello             -------->
  | client_certificate_type
 F| server_certificate_type
 U|
 L|                         <-------    HelloVerifyRequest
 L|
  | ClientHello             -------->
 D| client_certificate_type
 T| server_certificate_type
 L|
 S|                                            ServerHello
  |                                client_certificate_type
 H|                                server_certificate_type
 A|                                            Certificate
 N|                                      ServerKeyExchange
 D|                                     CertificateRequest
 S|                         <--------      ServerHelloDone
 H|
 A| Certificate
 K| ClientKeyExchange
 E| CertificateVerify
  | [ChangeCipherSpec]
  | Finished                -------->
  |
  |                                     [ChangeCipherSpec]
  |                         <--------             Finished
  +---

  +---                                                  ///+
 C|                                                        \ D
 O| Req: POST coap://rd.example.com/rd?ep=node1            \ T
 A| Payload:                                               \ L
 P| </temp>;ct=41;                                         \ S
  |    rt="temperature-c";if="sensor",                     \
 R| </light>;ct=41;                                        \ R
 D|    rt="light-lux";if="sensor"                          \ E
  |                         -------->                      \ C
 R|                                                        \ O
 E|                                                        \ R
 G|                                     Res: 2.01 Created  \ D
 .|                         <--------  Location: /rd/4521  \
  |                                                        \ L
  +---                                                     \ A
                                                           \ Y
                           *                               \ E
                           * (time passes)                 \ R
                           *                               \
  +---                                                     \ P
 C|                                                        \ R
 O|              Req: GET coaps://sensor.example.com/temp  \ O
 A|                         <--------                      \ T
 P|                                                        \ E
  | Res:  2.05 Content                                     \ C
 G| Payload:                                               \ T
 E| 25.5                     -------->                     \ E
 T|                                                        \ D
  +---                                                  ///+

    Figure 1: DTLS/CoAP exchange using Resource Directory.

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 2 Dec 2014 11:55:18 +0000

Dear Hannes

It seems to me that you are fixed on the OMA LWM2M use case. What you are describing is the special case where the RD is also an intermediary that forwards all requests and is the only remote endpoint for the sensor. This is, however, only the case for applications implementing the OMA specification! It is a very good pattern, but it is not the only one.

The general use case in the CoRE WG is the following: Sensor, RD, application endpoint, and potential intermediaries are completely independent. The sensor is primarily a CoAP server that provides access to its sensors through Web resources. To register with the RD (here the sensor is a CoAP client), it performs a full DTLS handshake as DTLS client. Later the application endpoint discovers the sensor through the RD. To interact with the sensor, the application endpoint performs a new full handshake as DTLS client where the sensor must act as DTLS server. The application is communicating with the sensor directly, that is, without the RD involved. This use case is relevant for converging infrastructures and peer-to-peer interaction (usually in local networks).

Alternatively, the application endpoint could discover the sensor through multicast discovery. Here, the sensor responds to coap requests and returns a list of coaps links to its resources in the CoRE Link Format.

Best regards
Matthias

-----Original Message-----
From: dtls-iot [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Dienstag, 2. Dezember 2014 10:36
To: [email-masked]
Subject: [Dtls-iot] Constrained Server (again)

I have tried to come up with some text for the constrained server case and I am wondering whether it addresses the comments raised earlier (or are we are talking past each other).

------

4. Constrained Servers

When a constrained client uploads sensor data to a server infrastructure it may use CoAP by pushing the data via a POST to a pre-configured endpoint on the server. In certain circumstances this might be too limiting and additional functionality is needed, as shown in Figure 1.

Figure 1 shows a sensor starting with a DTLS exchange with a resource server to register available resources. The initial DTLS interaction between the sensor, acting as a DTLS client, and the resource server, acting as a DTLS server, will be a full DTLS handshake. Once this handshake is complete both parties have established the DTLS record layer, which can subsequently be used to secure the CoAP message exchange, which starts with a the resource registration. Details about the resource registry capabilities can be found in [I-D.ietf-core-resource-directory].

After some time (assuming that the client regularly refreshes its
registration) the resource server receives a request (not shown) from an application to retrieve the temperature information from the sensor.
This request is relayed by the resource directory to the sensor using a GET message exchange. The already established DTLS record layer can be used to secure the message exchange.

                                                 Resource
    Sensor                                       Directory
    ------                                       ---------

  +---
  |
  | ClientHello             -------->

  +---                                                  ///+
 C|                                                        \ D

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Dec 2014 13:07:19 +0100

Hi Matthias,

On 12/02/2014 12:55 PM, Kovatsch Matthias wrote:
> Dear Hannes
> 
> It seems to me that you are fixed on the OMA LWM2M use case. What you
> are describing is the special case where the RD is also an
> intermediary that forwards all requests and is the only remote
> endpoint for the sensor. This is, however, only the case for
> applications implementing the OMA specification! It is a very good
> pattern, but it is not the only one.

I had intentionally chosen that case since I wanted to demonstrate a
case that allows me to have the sensor as a DTLS client and the cloud
infrastructure running the DTLS server.

> 
> The general use case in the CoRE WG is the following: Sensor, RD,
> application endpoint, and potential intermediaries are completely
> independent. The sensor is primarily a CoAP server that provides
> access to its sensors through Web resources. To register with the RD
> (here the sensor is a CoAP client), it performs a full DTLS handshake
> as DTLS client. Later the application endpoint discovers the sensor
> through the RD. To interact with the sensor, the application endpoint
> performs a new full handshake as DTLS client where the sensor must
> act as DTLS server.
> The application is communicating with the sensor
> directly, that is, without the RD involved. This use case is relevant
> for converging infrastructures and peer-to-peer interaction (usually
> in local networks).
> 
> Alternatively, the application endpoint could discover the sensor
> through multicast discovery. Here, the sensor responds to coap
> requests and returns a list of coaps links to its resources in the
> CoRE Link Format.
Thanks. This made it quite clear what you want.

This will obviously lead to a different profile since some of the
assumptions I made in the current text are less likely to be valid in
such a scenario. I will figure out what the "impact" for the text
actually is.

Ciao
Hannes

> 
> Best regards Matthias
> 
> 
> -----Original Message----- From: dtls-iot
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig 
> Sent: Dienstag, 2. Dezember 2014 10:36 To: [email-masked] Subject:
> [Dtls-iot] Constrained Server (again)
> 
> I have tried to come up with some text for the constrained server
> case and I am wondering whether it addresses the comments raised
> earlier (or are we are talking past each other).
> 
> ------
> 
> 
> 4. Constrained Servers
> 
> When a constrained client uploads sensor data to a server
> infrastructure it may use CoAP by pushing the data via a POST to a
> pre-configured endpoint on the server. In certain circumstances this
> might be too limiting and additional functionality is needed, as
> shown in Figure 1.
> 
> exchange, which starts with a the resource registration. Details
> about the resource registry capabilities can be found in
> registration) the resource server receives a request (not shown) from
> an application to retrieve the temperature information from the
> sensor. This request is relayed by the resource directory to the
> sensor using a GET message exchange. The already established DTLS
> record layer can be used to secure the message exchange.
> 
> Resource Sensor                                       Directory 
> ------                                       ---------
> 
> +--- | | ClientHello             --------> | client_certificate_type 
> F| server_certificate_type U| L|                         <-------
> HelloVerifyRequest L| | ClientHello             --------> D|
> client_certificate_type T| server_certificate_type L| S|
> ServerHello |                                client_certificate_type 
> H|                                server_certificate_type A|
> Certificate N|
> ServerKeyExchange D|
> CertificateRequest S|                         <--------
> ServerHelloDone H| A| Certificate K| ClientKeyExchange E|
> CertificateVerify | [ChangeCipherSpec] | Finished
> --------> | |                                     [ChangeCipherSpec] 
> |                         <--------             Finished +---
> 
> +---                                                  ///+ C|
> \ D O| Req: POST coap://rd.example.com/rd?ep=node1            \ T A|
> Payload:                                               \ L P|
> </temp>;ct=41;                                         \ S |
> rt="temperature-c";if="sensor",                     \ R|
> </light>;ct=41;                                        \ R D|
> rt="light-lux";if="sensor"                          \ E |
> -------->                      \ C R|
> \ O E|                                                        \ R G|
> Res: 2.01 Created  \ D .|                         <--------
> Location: /rd/4521  \ |
> \ L +---                                                     \ A \ Y 
> *                               \ E * (time passes)                 \
> R *                               \ +---
> \ P C|                                                        \ R O|
> Req: GET coaps://sensor.example.com/temp  \ O A|
> <--------                      \ T P|
> \ E | Res:  2.05 Content                                     \ C G|
> Payload:                                               \ T E| 25.5
> -------->                     \ E T|
> \ D +---                                                  ///+
>

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 2 Dec 2014 15:04:11 +0000

> I had intentionally chosen that case since I wanted to demonstrate a case
> that allows me to have the sensor as a DTLS client and the cloud

Okay, but then the heading "Constrained Servers" is very misleading because there is no constrained DTLS server and the sensor cannot act as stand-alone CoAP server.

> > performs a new full handshake as DTLS client where the sensor must act
> > as DTLS server.
> > The application is communicating with the sensor directly, that is,
> > without the RD involved. This use case is relevant for converging
> > infrastructures and peer-to-peer interaction (usually in local
> > networks).
> >
> This will obviously lead to a different profile since some of the assumptions I
> made in the current text are less likely to be valid in such a scenario. I will
> figure out what the "impact" for the text actually is.

In this case, the document should simply make clear that it is a profile for constrained DTLS clients and not for constrained DTLS in general. My main problem with the current draft is that it implicitly forces all CoAP solutions into the OMA LWM2M model. There is no problem when we explicitly split it up into a DTLS client and a DTLS server profile.

Implementation- and code-size-wise there is almost no difference between DTLS client and server role. Both sides have to implement the handshake state machine. Looking at the numbers from https://people.inf.ethz.ch/mshafagh/master_thesis_Hossein_Shafagh_PKC_in_the_IoT.pdf#80 (document page 68), clients consume slightly more memory due to the ClientHello control path. The overhead of implementing both roles is minimal, since the state machine and all crypto functions are shared.

Ciao
Matthias