Subject: [Dtls-iot] Fwd: Review of the DTLS/TLS Profile Draft

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Mar 2015 12:53:04 +0100

Hi Simon,

thanks for your review and for doing an editorial pass of the document
(which got incorporated directly into Github).

Your question about the keep-alive section made me re-read it again and
I noticed that I haven't described the actual problem that is supposed
to be solved.

For that reason I change the section and here is the new version:

-----

12.  Keep-Alive

   Application layer communication may create state at the endpoints and
   this state my expire at some time.  For this reason, applications
   define ways to refresh state, if necessary.  While the application
   layer exchanges are largely outside the scope of the underlying TLS/
   DTLS exchange similar state considerations also play a role at the
   level of TLS/DTLS.  While TLS/DTLS also creates state in form of a
   security context (see the security parameter described in Appendix A6
   in RFC 5246) at the client and the server this state information does
   not expire.  However, network intermediaries may also allocate state
   and require this state to be kept alive.  Failure to keep state alive
   at a stateful packet filtering firewall or at a NAT may result in the
   inability for one node to reach the other since packets will get
   blocked by these middleboxes.  Periodic keep-alive messages exchanged
   between the TLS/DTLS client and server keep state at these
   middleboxes alive.  According to measurements described in
   [HomeGateway] there is some variance in state management practices
   used in residential gateways but the timeouts are heavily impacted by
   the choice of the transport layer protocol: timeouts for UDP are
   typically much shorter than those for TCP.

   RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the
   other peer is still alive.  As an additional feature, the same
   mechanism can also be used to perform Path Maximum Transmission Unit
   (MTU) Discovery.

   A recommendation about the use of RFC 6520 depends on the type of
   message exchange an IoT device performs and the number of messages
   the application needs to exchange as part of their application
   functionality.  There are three types of exchanges that need to be
   analysed:

   Client-Initiated, One-Shot Messages

      This is a common communication pattern where IoT devices upload
      data to a server on the Internet on an irregular basis.  The
      communication may be triggered by specific events, such as opening
      a door.

      Since the upload happens on an irregular and unpredictable basis
      and due to renumbering and Network Address Translation (NAT) the
      DTLS handshake may need to be re-started (ideally using session
      resumption, if possible).

      In this case there is no use for a keep-alive extension for this
      scenario.

   Client-Initiated, Regular Data Uploads

      This is a variation of the previous case whereby data gets
      uploaded on a regular basis, for example, based on frequent
      temperature readings.  If neither NAT bindings nor IP address
      changes occurred then the record layer will not notice any
      changes.  For the case where the IP address and port number
      changes, it is necessary to re-create the record layer using
      session resumption.

      In this scenario there is no use for a keep-alive extension.  It
      is also very likely that the device will enter a sleep cycle in
      between data transmissions to keep power consumption low.

   Server-Initiated Messages

      In the two previous scenarios the client initiated the protocol
      interaction and maintains it.  Since messages to the client may
      get blocked by middleboxes the initial connection setup is
      triggered by the client and then kept alive by the server.

      For this message exchange pattern the use of DTLS heartbeat
      messages is quite useful but may have to be coordinated with
      application exchanges (for example when the CoAP resource
      directory is used) to avoid redundant keep-alive message
      exchanges.  The MTU discovery mechanism, which is also part of
      [RFC6520], is less likely to be relevant since for many IoT
      deployments the most constrained link is the wireless interface
      between the IoT device and the network itself (rather than some
      links along the end-to-end path).  Only in more complex network
      topologies, such as multi-hop mesh networks, path MTU discovery
      might be appropriate.  It also has to be noted that DTLS itself
      already provides a basic path discovery mechanism (see
      Section 4.1.1.1 of RFC 6347 by using the fragmentation capability
      of the handshake protocol).

   For server-initiated messages the heartbeat extension is RECOMMENDED.

-----

Is this new text an improvement that answers your question?

Ciao
Hannes

-------- Forwarded Message --------

*From:*Lemay, Simon [mailto:[email-masked]]
*Sent:* 05 February 2015 21:27
*To:* Hannes Tschofenig
*Subject:* Re: Review of the DTLS/TLS Profile Draft

Hey hannes, how are you

I Skyped you a message but then i figure that email would probably be
better for this

I finished reviewing the document, it looks really good,

I had one question, in section 12 - keep-alive, there is talk of keep
alive in different scenarios and re-creating the record layer depending
on the sporadicity of the message transmission.  Is the suggestion to
re-create the layers after each message or is there a tolerance metric
that should be kept (this might be out of scope for this document or
implementation specific)?

I also made  a few markup (mostly syntaxe and reformulation) if you want
i can fork your repo, make the markup there and pull request it to see
if you like the changes (the changes would not affect content or meat of
the work)

Cheers and good work, that was a good read :D .

Simon