Subject: [Dtls-iot] DTLS fragmentation

From: "Kovatsch Matthias" <[email-masked]>
Date: Sun, 7 Dec 2014 18:22:17 +0000

Dear list

I have been wondering if the DTLS Profile should constrain the fragmentation mechanism of DTLS. It is somewhat "chaotic," as it allows fragments of different size that can also overlap. This can be quite a burden for constrained devices. Shouldn't the DTLS Profile maybe simplify this for DICE? I am aware that this will then also affect the cloud side.

Another problem that came up during interoperability tests is the assignment of DTLS messages to UDP datagrams. When the system has large enough buffers, the DTLS implementation can simply put all messages of a flight into a single datagram. Systems with highly constrained buffers, however, often expect each message in a separate datagram. Should the Profile do something about this? (Sorry if I simply overread this in the draft!)

Ciao
Matthias

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Sun, 7 Dec 2014 20:02:54 +0000

+1

Both very valid observations we also came across and would be nice to be in the profile.

Sandeep

Sent from Mobile

-------- Original message --------
From: Kovatsch Matthias <[email-masked]>
Date: 2014/12/07 19:22 (GMT+01:00)
To: [email-masked]
Subject: [Dtls-iot] DTLS fragmentation

Dear list

Ciao
Matthias

_______________________________________________
dtls-iot mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtls-iot

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Michael StJohns <[email-masked]>
Date: Sun, 07 Dec 2014 18:47:08 -0500

> Another problem that came up during interoperability tests is the assignment of DTLS messages to UDP datagrams. When the system has large enough buffers, the DTLS implementation can simply put all…

The major problem with the above is that both sides need to know how to 
do this and there isn't support in the base standard (DTLS) for this 
approach.  That makes it difficult to write a profile.

What would need to be done is to write a draft describing how to use an 
extension to signal this behavior.  Then that specification could be 
referenced by the profile.

There's also the problem that although "server" initiated extensions are 
technically possible, there isn't actually a worked example and you 
would need both client and server versions of a "please don't fragment 
in a weird way" extension.

The latter issue you mention is probably manageable.  What you're 
talking about is splitting a "flight" of messages across a number of UDP 
datagrams.  Section 3.2.3  of the DTLS spec already deals with this I 
believe.  Is there something else that you think needs to be said?

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 8 Dec 2014 09:54:36 +0100

On Sun, Dec 7, 2014 at 7:22 PM, Kovatsch  Matthias <[email-masked]> wrote:
> Dear list
>
> I have been wondering if the DTLS Profile should constrain the fragmentation mechanism of DTLS. It is somewhat "chaotic," as it allows fragments of different size that can also overlap.

Could you elaborate on that. On which part of DTLS do you refer to? Is
that the handshake message fragmentation mechanism? If yes, I don't
see how that fits your description of the fragmentation mechanism:
"When transmitting the handshake message, the sender divides the
message into a series of N contiguous data ranges.  ... The ranges
SHOULD NOT overlap."

regards,
Nikos

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 9 Dec 2014 09:57:50 +0000

> > I have been wondering if the DTLS Profile should constrain the
> fragmentation mechanism of DTLS. It is somewhat "chaotic," as it allows
> fragments of different size that can also overlap.
> 
> Could you elaborate on that. On which part of DTLS do you refer to? Is that
> the handshake message fragmentation mechanism? If yes, I don't see how
> that fits your description of the fragmentation mechanism:
> message into a series of N contiguous data ranges.  ... The ranges SHOULD
> NOT overlap."

In my opinion this SHOULD NOT should be a MUST NOT for IoT devices. Furthermore, it would be good to have a general idea what fragment sizes to expect, so that the buffers can be reasonably dimensioned.

Ciao
Matthias

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 09 Dec 2014 11:07:18 +0100

Matthias,

"Kovatsch  Matthias" <[email-masked]> writes:

> In my opinion this SHOULD NOT should be a MUST NOT for IoT
> devices. Furthermore, it would be good to have a general idea what
> fragment sizes to expect, so that the buffers can be reasonably
> dimensioned.

I presume that constrained devices will likely have static buffers with
a fixed size. I do not see how they would dynamically adjust their size.

Regards
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 09 Dec 2014 21:15:10 +0100

Hi Matthias,

thanks for raising this issue.

I would like to focus on the second issue you highlighted first.

> Another problem that came up during interoperability tests is the
> assignment of DTLS messages to UDP datagrams. When the system has
> large enough buffers, the DTLS implementation can simply put all
> messages of a flight into a single datagram. Systems with highly
> constrained buffers, however, often expect each message in a separate
> datagram. Should the Profile do something about this? (Sorry if I
> simply overread this in the draft!)

But there is clearly a tradeoff here since sending each DTLS message
separately leads to more on-the-wire overhead.

Certainly, if you do not have large enough buffers then you will not be
able to combine multiple messages into a single UDP datagram.

Where do you think text should go? What recommendation should we give?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 09 Dec 2014 21:20:17 +0100

Hi Olaf,

> a fixed size. I do not see how they would dynamically adjust their size.

It heavily depends on your implementation preferences on how to do the
memory management.

Here is info about the memory model in mbed (see
http://developer.mbed.org/handbook/Memory-Model) and how dynamic memory
can be allocated.

Ciao
Hannes

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 10 Dec 2014 13:52:48 +0100

Hannes,

> It heavily depends on your implementation preferences on how to do the

No, not at all. Dynamic memory management not only requires some more
resources (RAM and code) but also makes evaluation of runtime behavior
very difficult for non-trivial applications.

> http://developer.mbed.org/handbook/Memory-Model) and how dynamic memory

I fail to see how this generic overview gives any additional information
that could be of use in this discussion?

Regards
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 10 Dec 2014 14:24:45 +0100

Hi Olaf,

> very difficult for non-trivial applications.

What kind of runtime behavior analysis are you thinking about?

> that could be of use in this discussion?
This is just one example of a system that offers dynamic memory
allocation for the application developer. As such, you cannot assume
that all systems use static buffer allocation for IoT applications.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 10 Dec 2014 14:27:17 +0100

Hi Matthias,

I now want to respond to your initial question:

On 12/07/2014 07:22 PM, Kovatsch Matthias wrote:
> fragmentation mechanism of DTLS. It is somewhat "chaotic," as it
> allows fragments of different size that can also overlap. This can be
> quite a burden for constrained devices. Shouldn't the DTLS Profile
> maybe simplify this for DICE? I am aware that this will then also
> affect the cloud side.

I re-read the spec with this regard and I ran into this paragraph:

"
   When a DTLS implementation receives a handshake message fragment, it
   MUST buffer it until it has the entire handshake message.  DTLS
   implementations MUST be able to handle overlapping fragment ranges.
   This allows senders to retransmit handshake messages with smaller
   fragment sizes if the PMTU estimate changes.
"

I fear that we can not change this functionality in the profile document.

Ciao
Hannes

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 10 Dec 2014 14:31:21 +0100

> What kind of runtime behavior analysis are you thinking about?

Depends on your implementation. Typical algorithms need to trade between
internal and external fragementation.

> that all systems use static buffer allocation for IoT applications.

Yes, it is an existence proof but not more. There is no doubt that
malloc/new are available for many embedded OS. The question is whether
or not one wants to use it.

Regards
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 10 Dec 2014 20:09:31 +0100

Olaf,

I guess we indeed got a bit side-tracked in our discussion.

You asked the following question:
"
Furthermore, it would be good to have a general idea what fragment sizes
to expect, so that the buffers can be reasonably dimensioned.
"

Unfortunately, I have difficulties answering that question since it
depends on a number of aspects, such as
 * what type of credential is being used,
 * what key size is used,
 * how long the identifiers are,
 * how large the certificates are (if certificate-based authentication
is used),
 * what extensions are implemented,
etc.

If someone has some specific examples that they find worthwhile to
include then I will do it. I fear, however, that we cannot state the
maximum buffer size in the document.

Ciao
Hannes

---

From: Robert Cragie <[email-masked]>
Date: Wed, 10 Dec 2014 22:49:07 +0000

Firstly, regarding memory allocation in embedded systems. There are many 
ways of implementing memory allocation "dynamically" which doesn't mean 
using the heap (malloc()/free() or new/delete). For stacks, buffer pools 
are often used for packets/datagrams, which can be efficiently allocated 
and freed. Therefore, I personally don't think it figures particularly 
in the discussion.

Regarding the two issues originally raised i.e. fragmentation and number 
of handshake messages per flight: it is all about the MTU. If the MTU is 
1280, for example, it is likely in many cases DTLS fragmentation will 
not be needed and furthermore it is likely that each flight will be able 
to be contained in a single UDP datagram. This would very likely be the 
case for PSK and RPK cipher suites (although I confess I haven't done 
the actual numbers yet). It is probably only the cipher suites where 
certificates are being sent back and forth that would cause 
fragmentation in the 1280 MTU case. As already mentioned by Hannes, the 
DTLS handshake record has to be reassembled in its entirety for the 
verify_data calculations so space has to be allocated for it, so the 
certificate-based cipher suites are again going to require the largest 
amount of buffering and/or storage. If the MTU is much smaller, the two 
issues Matthias originally mentioned will indeed come into play and it 
may well be worth exploring what MTUs are available in which 
implementations. The SMS case, for example, seems particularly 
challenging, however small MTU sizes will be challenging for the 
application layer as well, of course.

Robert

On 10/12/2014 13:31, Olaf Bergmann wrote:
> Hannes Tschofenig<[email-masked]>  writes:
>
>> Hi Olaf,

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Dec 2014 16:02:38 +0100

I guess I agree with your observations about the memory management.

The issues raised by Matthias and Olaf regarding fragmentation are good
but it is just the question what we should do about them.

Here are a few things we could do:

a) provide examples of exchanges, including their message size.
[I personally would prefer to put them into the LWIG TLS document instead.]

b) provide buffer size recommendations
[While useful I don't have any suggestion what to write.]

c) clarifications regarding the terminology (e.g., flight, DTLS message,
fragment, datagram)
[Maybe it is useful to provide a few examples of how messages could look
like.]

d) recommendations that change the DTLS/TLS spec with respect to the
overlapping fragments
[We cannot really do that as part of this work (even though I do not
like the idea of overlapping fragments either.]

Ciao
Hannes

---

From: Robert Cragie <[email-masked]>
Date: Thu, 11 Dec 2014 16:45:13 +0000

Hi Hannes,

My suggestion was to look at typical MTUs used in constrained 
environments, which is closest to (a), I guess. If the small MTU case is 
mostly an edge case and the 1280-1500 MTU case is typical then I think 
we can state that there should be no need for fragmentation unless it is 
a certificate-based cipher suite and we can also recommend putting 
multiple handshake messages in a single UDP datagram. If you think this 
makes more sense for the LWIG document, we can put it there.

I don't think (b) is going to be particularly useful in the profile 
document. Again, it might make more sense to do this in the LWIG document.

(c) might help but there is an element of RTFM here - it is all in the 
original specs. I do think examples would be good though. Perhaps pick 
the three CoAP cipher suites and show what that might look like for 
small and standard (i.e. 1280) MTU sizes.

Regarding (d), the DTLS spec. already allows overlapping fragments. It 
has to as it has to accommodate MTU resizing. Whilst it complicates 
processing slightly, I don't think it is a major concern as the 
handshake message needs to be reconstructed fully anyway.

Robert

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 11 Dec 2014 18:09:36 +0100

Robert Cragie <[email-masked]> writes:

> Firstly, regarding memory allocation in embedded systems. There are
> many ways of implementing memory allocation "dynamically" which
> doesn't mean using the heap (malloc()/free() or new/delete). For
> stacks, buffer pools are often used for packets/datagrams, which can
> be efficiently allocated and freed. Therefore, I personally don't
> think it figures particularly in the discussion.

Again: You are describing static memory management (a fixed number of
buffers in a pool, each with a fixed size).

If you want to review dynamic storage allocation techniques and their
implications, I can recommend reading Paul R. Wilson, Mark S. Johnstone,
Michael Neely, David Boles: Dynamic storage allocation: A survey and
critical review. In: Memory Management.  Lecture Notes in Computer
Science Volume 986, 1995, pp 1--116.

Regards
Olaf

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 11 Dec 2014 18:19:02 +0100

> [While useful I don't have any suggestion what to write.]

I think (a) would be good to have (and yes, sounds more like the LWIG
TLS document). From (a), implementors might be able to infer (b), don't
they?

Regards
Olaf

---

From: Robert Cragie <[email-masked]>
Date: Thu, 11 Dec 2014 19:36:04 +0000

Well, it's a moot point whether it is static or dynamic, which is why I 
put "dynamically" in quotes. "static" and "fixed" do not mean the same 
thing.

Either way, I don't think it figures in the discussion.

Robert

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sat, 13 Dec 2014 11:12:09 +0000

> > [I personally would prefer to put them into the LWIG TLS document

LWIG sounds like a good place.
I will try to provide some traces of different handshakes with some data like sizes and timings.

> > b) provide buffer size recommendations [While useful I don't have any
> > suggestion what to write.]
> 
> I think (a) would be good to have (and yes, sounds more like the LWIG TLS
> document). From (a), implementors might be able to infer (b), don't they?

@Olaf: it does not matter if the buffers are static or allocated. Both ways you need an idea how much should be reserved, so that all handshakes will work while keeping enough RAM for the rest of the system.

I think Roberts comment to dimension the buffers according to the 1280-byte MTU is a good way to go. All flights of PSK and RPK handshakes fit into this size. The size of certificates can explode easily, while you can also make them fit the 1280 bytes. There might be a problem, however, when DTLS cannot re-use the IP packet buffer and needs its own buffer (e.g., when flights a split into multiple datagrams while having only one packet buffer). Then we directly blow one additional kilobyte of RAM. Hence, it would be good to fix both in the profile.

Ciao
Matthias