Subject: [Dtls-iot] Fwd: [dice] #2 (profile): Keep-Alive Extension

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 21 Jun 2014 20:19:02 +0200

-------- Original Message --------
Subject: [dice] #2 (profile): Keep-Alive Extension
Date: Fri, 20 Jun 2014 12:35:51 -0000
From: dice issue tracker <[email-masked]>
To: [email-masked]
CC: [email-masked]

#2: Keep-Alive Extension

 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the other
 peer is still alive. The same mechanism can also be used to perform path
 MTU discovery.

 I believe there are three types of exchanges:

 1) Client-initiated, one-shot messages.

 This is a common case where IoT devices sleep regularly to interact with
 some cloud server to upload data on an irregular basis. After the data
 upload the device goes to sleep.

 When used with DTLS then one can assume that session resumption is used.

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

 2) Client-initiated, regular data uploads.

 This is a variation of case (1) whereby data gets uploaded more regularly
 so that the DTLS context is still setup. If neither NAT bindings nor IP
 address changes occurred then the DTLS record layer will not notice any
 changes. For the case where IP and port changes happened it is necessary
 to re-create the DTLS record layer using session resumption.

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

 3) Server-initiated messages

 Unlike in the previous scenarios the server triggers the interaction.
 Since messages to the client may get blocked by intermediaries, such as
 NATs and stateful packet filtering firewalls, the initial connection setup
 is triggered by the server and then kept alive. State expires fairly
 quickly at middleboxes and therefore regular heartbeats are necessary.

 These keep-alive messages may be exchanged at the application layer or
 within DTLS itself.

 For this message exchange pattern the use of DTLS heartbeat messages is
 quite useful. The MTU discovery mechanism, on the other hand, is less
 likely to be relevant since for many IoT deployments the must constrained
 link is the wireless interface at the IoT device itself rather than
 somewhere in the network. In more complex network topologies the situation
 might be different.

 Recommendation: Only for the last category, the heartbeat extension is
 useful. It might therefore be useful to add the description of these three
 categories into the document to provide further background information and
 to motivate the extension.

-- 
---------------------------------------+-------------------------------
 Reporter:  [email-masked]  |      Owner:  Hannes Tschofenig
     Type:  defect                     |     Status:  new
 Priority:  major                      |  Milestone:
Component:  profile                    |    Version:
 Severity:  Active WG Document         |   Keywords:
---------------------------------------+-------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dice/trac/ticket/2>
dice <http://tools.ietf.org/dice/>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 22 Jun 2014 11:43:56 -0400

> When used with DTLS then one can assume that session resumption is used.

Perhaps rather than assume, one could say that, "since the upload is on an
irregular and unpredicable basis and due to renumbering and NAT, may
originate from unpredictable origins, only a new session, or a resumed can be
used"

    > changes.

(and, this is clearly a place where IPv6 has a definite win)

    > to motivate the extension.

I agree.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Jun 2014 08:15:15 +0200

Hi Michael,

> originate from unpredictable origins, only a new session, or a resumed can be
A much better wording. Thanks

> (and, this is clearly a place where IPv6 has a definite win)
Yes, but I am not sure whether I should state that since this document
isn't really about the pros and cons of IPv6.

Ciao
Hannes